Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

timeline: introduce a Send Queue API #3361

Closed
14 tasks done
bnjbvr opened this issue Apr 29, 2024 · 2 comments · Fixed by #3616
Closed
14 tasks done

timeline: introduce a Send Queue API #3361

bnjbvr opened this issue Apr 29, 2024 · 2 comments · Fixed by #3616
Assignees

Comments

@bnjbvr
Copy link
Member

bnjbvr commented Apr 29, 2024

  • Make it so that the sending queue is shared by all the timeline instances of the same room (live or detached), so that local echoes appear on all the live/detached timelines, if need be
  • Allow retry sending
  • Allow enabling/disabling the sending queue globally
  • Change course to have a per-room sending queue enablement flag
  • Expose whenever an event couldn't be sent because of an API error (status code 4XX or 5XX)
  • Mark such events from the queue as wedged, and don't block the queue for them.
  • Store and manage unsent events on disk
    • make all the ruma *EventContent types serializable and deserializable with a type (PR)
    • implement state store backends to save events on disk
    • reload all the rooms that have at least one pending event when the Client restarts
    • timeline: mark wedged local echoes with the proper failure send state
  • Allow redacting local echoes in a timeline
  • Allow editing local echoes in a timeline
  • Allow sending raw events

@maan2003
Copy link
Contributor

related #3152

@bnjbvr
Copy link
Member Author

bnjbvr commented May 31, 2024

Ah thanks, this issue subsumes that one 👍

@bnjbvr bnjbvr changed the title timeline: sending messages improvements timeline: introduce a Send Queue API Jun 19, 2024
bnjbvr added a commit to ruma/ruma that referenced this issue Jun 24, 2024
This allows deserializing all the `*EventContent` types into a parent `Any{...}EventContent`, assuming we know the type of the underlying event.

Required for serializing/deserializing the content of events we'd like to send, across application restarts, as in matrix-org/matrix-rust-sdk#3361 for the Rust SDK.

---

* events: add deserialize_with_type to all the *EventContent types

* events: add smoke test for deserializing an event content with a type

* events: add a test for deserializing a secret storage key event content

* events: add fix for correctly matching events with a type fragment

* Address review comments.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants