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

Implement outbox system #133

Open
chrisbobbe opened this issue May 26, 2023 · 2 comments
Open

Implement outbox system #133

chrisbobbe opened this issue May 26, 2023 · 2 comments
Labels
a-api Implementing specific parts of the Zulip server API a-model Implementing our data model (PerAccountStore, etc.)

Comments

@chrisbobbe
Copy link
Collaborator

Something like this, maybe. From discussion:

            User cancels the scheduled send.
           ┌────────────────────────────────────────────────────────────────────────┐
           │                                                                        │
           │                                                                        │
           │                                   User cancels during send (#4170).    │
           │                                  ┌───────────────────────────────────┐ │
           │                                  │                                   │ │
           │                                  │                                   │ │
           │                                  │                Event received,    │ │
(create)   │      Time for the scheduled      │                or we abandoned    │ │
  │        │      send (a try/retry).         │    200.        the queue.         ▼ ▼
  └► should-send ───────────────────────► sending ─────► sent ────────────────► (delete)
       │ ▲ ▲                                │ │                                     ▲
       │ │ │                                │ │                                     │
       │ │ │ App quit: schedule auto-retry. │ │                                     │
       │ │ │                                │ │                                     │
       │ │ │ 5xx, network error, or (with   │ │                                     │
       │ │ │ #4170) 60s network timeout:    │ │                                     │
       │ │ │ schedule auto-retry with       │ │                                     │
       │ │ │ backoff.                       │ │ 4xx.                                │
       │ │ └────────────────────────────────┘ └───────────────────────┐             │
       │ │                                                            │             │
       │ │                                                            │    User     │
       │ │ User requested a retry; schedule to run immediately.       ▼    cancels. │
       │ └──────────────────────────────────────────────────────── failed ──────────┘
       │                                                              ▲
       │                                                              │
       │ Too old: message is "better never than late". Too much time  │
       │ from creation or last user-requested retry.                  │
       └──────────────────────────────────────────────────────────────┘
@gnprice
Copy link
Member

gnprice commented May 26, 2023

From a user perspective this feature means:

  • We retry sending the message, if we can't reach the server at the moment you first try (perhaps you're on a train in a tunnel, or on the road with spotty cell connections) but are able to sometime soon after, like minutes after.
  • When we give up on sending the message, we give the user feedback so they know it wasn't sent.
  • When we've given up on a message, we give the user the option to retry sending it.

@gnprice gnprice added a-api Implementing specific parts of the Zulip server API a-model Implementing our data model (PerAccountStore, etc.) labels Jun 14, 2023
@gnprice gnprice added this to the Beta milestone Jun 15, 2023
@gnprice gnprice modified the milestones: Beta, Launch Sep 22, 2023
@gnprice
Copy link
Member

gnprice commented Mar 21, 2024

An implementation note: this is what the method PerAccountStore.sendMessage is for.

Currently that method does nothing other than make the underlying sendMessage API request. When we implement this issue, the same method will instead create a new outbox-message in the subsystem described above.

As a matter of code organization, that outbox data will probably want to live on its own class defined in its own file; PerAccountStore will just hold onto an instance of that class, and PerAccountStore.sendMessage will delegate to that. See Inbox and StreamStore for existing examples (showing two somewhat different versions of that pattern).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a-api Implementing specific parts of the Zulip server API a-model Implementing our data model (PerAccountStore, etc.)
Projects
Status: No status
Development

No branches or pull requests

2 participants