No, I mean in general, that's the hard problem. The main goal is that the user wants to do something, but there's an instrumental goal that the system has to be

No, I mean in general, that's the hard problem. The main goal is that the user wants to do something, but there's an instrumental goal that the system has to be resilient to typical real world problems, otherwise the users will have a bad time. For example the user wants to interact with the service, order something, check for new messages or send one. On the happy path things are trivial, easy, synchronous, even quite resilient. There's not much complexity to manage on "no new message" or "add to cart, yes, buy with saved card, ship to saved address, k thx bye", if the browser or server crashes, or there's a network error, the interaction is short, easy to retry, problems are not hidden (quasi instant feedback) But as the total interaction time increases, as the state the user would need to reproduce grows (adding new card, shipping/billing address, adding a lot of stuff into the card, writing a long message) the need for partial state sync arises.