• Single logical heartbeat/reminder fires reappeared more than once in the main session.
• Charlie's Matrix review found 57 inbound deliveries from 26 unique Matrix event_ids; 22/26were replayed2–4x`.
• Cleaning up duplicated Matrix account/listener state reduced one symptom but did not fully eliminate the broader replay/recovery behavior.

TL;DR

Implementing a strong deduplication key for both scheduled reminders and Matrix events may prevent replaying of prior events into the same session.

Guidance

• Investigate the delivery acknowledgement mechanism to ensure it is durably committed, preventing replay of already processed events.
• Review the restart/recovery path to identify why prior queued work is being replayed and implement a fix to prevent this behavior.
• Introduce a unique deduplication key for both scheduler and Matrix intake to prevent duplicate events from being enqueued into the session.
• Verify the effectiveness of these changes by repeating the reproduction sketch and comparing the results.

Example

No specific code snippet can be provided without more details on the implementation, but ensuring that each event (whether from scheduled reminders or Matrix events) has a unique identifier that can be checked against before processing could help prevent duplicates.

Notes

The exact implementation details of the scheduler, Matrix intake, and delivery acknowledgement mechanisms are not provided, which limits the specificity of the guidance. However, focusing on durable acknowledgement and unique deduplication keys should help mitigate the issue.

Recommendation

Apply a workaround by introducing a deduplication mechanism for events, as the root cause seems to be related to the lack of a strong dedup key and potentially non-durable delivery acknowledgements. This approach is chosen because it directly addresses the observed behavior and hypothesized causes without requiring an upgrade to a potentially non-existent fixed version.