Summing up the docs (this is not the official wording!):
The purpose of the transaction ID is to allow the homeserver to distinguish a new request from a retransmission.
The client should change the transaction ID value for each request (how is not specified; a monotonically increasing integer is recommended).
The homeserver identifies a request as a retransmission if the transaction ID and HTTP path are the same as a previous request.
The scope of a transaction ID is for a single device. If a client logs out and back in between two requests using the same transaction ID, they are considered distinct because logging in creates a new device [...]. If a client re-uses a transaction ID for the same endpoint after refreshing an access token, it will be assumed to be a duplicate request and ignored.
Apprise currently always uses a transaction ID of 0, and thus when the login session is retained (through _login()) only the first message that gets sent is actually accepted by the Matrix homeserver. All the subsequent ones are ignored and the homeserver replies with the internal event ID of the first message, since it believes that these new requests are indeed retransmissions.
Terminating and restarting the Python application that uses Apprise solves the problem because a new login session (and thus a new device, in Matrix terms) is created and the transaction ID of 0 is now valid for a (single) new request. The Apprise CLI client is thus immune from this issue since it (always, I presume?) starts from scratch without an estabilished session.
:mega: Notification Service(s) Impacted Matrix
:lady_beetle: Describe the bug
In Matrix's v3 API when a client sends a message the last URL segment is the Transaction Identifier.
Summing up the docs (this is not the official wording!):
Apprise currently always uses a transaction ID of
0, and thus when the login session is retained (through_login()) only the first message that gets sent is actually accepted by the Matrix homeserver. All the subsequent ones are ignored and the homeserver replies with the internal event ID of the first message, since it believes that these new requests are indeed retransmissions.Terminating and restarting the Python application that uses Apprise solves the problem because a new login session (and thus a new device, in Matrix terms) is created and the transaction ID of 0 is now valid for a (single) new request. The Apprise CLI client is thus immune from this issue since it (always, I presume?) starts from scratch without an estabilished session.
:bulb: Screenshots and Logs N/A
:computer: Your System Details:
:crystal_ball: Additional context