summaryrefslogtreecommitdiff
path: root/ui/lib/retry.js
diff options
context:
space:
mode:
authorOwen Jacobson <owen@grimoire.ca>2025-05-05 19:51:58 -0400
committerOwen Jacobson <owen@grimoire.ca>2025-05-05 21:00:37 -0400
commitd11ff421de581a835f1645b22d1f7f4304640b0c (patch)
tree3d61022b84ff56ebcc7c1789ce1a1f611c813895 /ui/lib/retry.js
parent8a329eb962eb98e89b41708d92b3f9298e4c21e1 (diff)
Use the outbox for more than just message sends.
A handful of operations are "synchronized" - that is, the server sends back information about them when the client asks to perform them, but notifies _all_ clients of completion through the event stream. As of this writing, these operations include sending and deleting messages, creating and deleting channels, and anything that creates new users. We can use the outbox for most of these. I've opted _not_ to use the outbox for creating users, as that often takes place when the client is not connected to the event stream (and can't be) and so cannot discover that the operation has been completed after it is sent. Outboxed tasks are objects, not closures, even though they behave in closure-like ways (`send()` carries out what amounts to "attempt this operation until it succeeds"). This is deliberate; I want the properties of incomplete tasks to be inspectable down the line, so that we can put them in the UI. If they're mere closures, we can't do that. It is deliberate that `outbox.postToChannel` et al do not return promises. I contemplated it, but it will interact weirdly with outbox serialization, when we get to that. Rather than relying on a promise to determine when an operation has completed, clients of `Outbox` should monitor its properties. (We can add additional view properties to make that easier.)
Diffstat (limited to 'ui/lib/retry.js')
0 files changed, 0 insertions, 0 deletions