Due to a quirk in InteractionResponse.send_message not returning a
message, all messages sent with an associated View would end up having
no message_id set. When multiple instances of a View are responded to
in a slash command context, this meant that the newest one would
override the storage of the older one. Ultimately leading to the first
view instance causing interaction failures.
Since fetching the original message is an unacceptable solution to the
problem due to incurred requests, the next best thing is to store an
intermediate interaction_id as a stop gap to differentiate between
the multiple instances. This change however, came with its own set of
complications.
Due to the interaction_id being an intermediate stop gap, the
underlying storage of the view store had to be changed to accommodate
the different way of accessing the data. Mainly, the interaction_id
key had to be quick to swap and remove to another key. This solution
attempts to change the interaction_id interim key with
a full fledged message_id key when it receives one if it's possible.
Note that the only way to obtain the interaction_id back from the
component interaction is to retrieve it from the MessageInteraction
data structure. This is because using the interaction_id of the button
press would be a different interaction ID than the one set as an
interim key. As a consequence, this stop gap only works for application
command based interactions. I am not aware of this bug manifesting in
component based interactions.
This patch also fixes a bug with ViewStore.remove_view not working due
to a bug being suppressed by a type: ignore comment. It also removes
the older __verify_integrity helper method since clean-up is already
done through View.stop() or View timeout.
Hopefully in the near future, the `/callback` endpoint will return
actual message data and this stop gap fix will no longer be necessary.
The older code attempted to be clever and sync component additions and
removals with what the message edit is doing. In some cases, this led
to the re-creation of those components causing lost attributes to be
dropped such as `_rendered_row` which would mess up handling of view
weights.
Instead of recreating the children list every time and keeping track
of additions and removals, this change just updates the old state with
the new state while ignoring any new or removed additions. This should
work fine in theory due to additions or removals already being present
before editing the View instance in the first place.
Closes#7231#7511
This allows users to call remove_item in a loop. Likewise, it prevents
the footgun of doing children.append(...) which does not uphold the
invariants with the weight system.
This is more consistent with the rest of the library which always has
the interaction as the first parameter. This has been done before in
the command extension as well, the first parameter is always either
self or the context.
Segments where readability was hampered were fixed by appropriate
format skipping directives. New code should hopefully be black
compatible. The moment they remove the -S option is probably the moment
I stop using black though.
If different persistent view instances are used within different
message_ids their callbacks will get called without differentiating
between them, leading to potential issues such as 404 errors. This
change makes it so N views with custom IDs bound to N message_ids
will no longer conflict with one another.
