Recoverable errors from fallible operation

[TylerBloom]

Recoverable errors from fallible operation

[TylerBloom]

couldn't you just do a read of the tournament state, check whether the operation would succeed

Yes, in general, this is possible; however, not all types fit this restriction. In particular, if you are working with a type that is defined in another crate, you might not have the ability to check the fallibility of an operation through a shared reference.

I rewatched the impl video on this and understand the design considerations behind the refresh better now and how they are at odds with what I'm specifically wanting. Ulimately, I'm wanting a cross between a left-right and a watch channel. This might be an idea for a seperate crate.

[jonhoo]

Can you give a motivating use-case for when operations might fail? I'm not opposed to this, but I want to make sure we land this complexity only if we think the solution actually addresses a real use-case.

Also, I think the fallibility needs to be exposed to writers in publish (i.e., try_publish), since append only appends to the log and does not (and cannot) apply the operation at all. At that point, I wonder whether the error is even still useful, because it might happen to some operation that's in the middle of the operational log. Which then leaves us in a weird middle-state.

More in the weeds: I don't think we need try_drop_*, since drop shouldn't be fallible.

[TylerBloom]

Sure, I can provide my use case. I also say the conversation you had on stream around this ticket, so I'll also expand on some things that you mentioned there.

I have a service that allows multiple users to send and receive updates to the same data structure. In my particular use case, these are tournaments (but you could replace "tournament" with "text document" and everything will still hold). Using websockets, a user sends an update message, the server processes it, and, on success, the same message is forwarded to all of the users so they can apply it to their local states. The received message can fail for a number of reasons (the user was out of sync, the server receives an improper or malicious message, etc).

Each multi-user session is managed by a tokio task. To reduce the DB-bound latency, this task maintains an in-memory copy of the tournament. This ensures that the session can always process incoming messages without any waiting on the DB. We persist the tournaments to the DB via a separate task that is responsible for persisting all tournaments. After every successful update from a user, we send a message to the persistence task to indicate that tournament has been updated and needs to be saved.

Ideally, the persistence task holds left-right reader handles to every tournament and will read from them only when it receives a message that a tournament has updated (this message is just the id of the tournament). Instead, there is a system of inter-task communication for retrieving clones of the tournament. Using left-right would both simplify the persistence problem and reduce the number of copies of the tournament that need to be made.

While watching your stream, you cleared up a misconception that I had. I was under the impression that when a writer appended to the operation log, it also applied the operation to the copy that it should have exclusive access to. This is somewhat important to this particular system because having immediate access to the success or failure of an operation is important as it dictates what the session task will do next. A similar effect could still be achieved by flushing after every update and receiving errors at that point; however, I don't think that is true in general.

[jonhoo]

Ah, interesting, thanks for the context! I may be missing something obvious, but couldn't you just do a read of the tournament state, check whether the operation would succeed, and the only do the (infallible) write operation if that is indeed the case. Then there'd be no need for fallible writes to be a thing.

The reason why writes are enqueued and applied only on a refresh, rather than applied directly, is that it allows left-right to return "early" from refresh so that the time spent waiting for readers to depart one "side" is time when the writing thread also gets to execute. It's a little hard to explain without a diagram, but it allows left-right to spend less time blocking the current thread overall.

[jonhoo]

That sounds about right 👍 I'll close this as wontfix, but please do post back if you end up building such a thing to aid in discovery!