Events and State - what's the vision for the future?

[da-kami]

Internally we now have an event based model, i.e. we append events to the Cfd and build (hydrate) the state of the Cfd from the list of events when we load it.

In the projection we still have states - mostly because the user interface has to be able to display something to the user, and a textual state (Pending Setup, Contract Setup, Open, ...) is easier to perceive than a list of events.
In a way the state is an aggregate of the events.

When we apply the events in porjection::Cfd we always set a state depending on the event, meaning that the last event basically decides the state. While this sounds good in theory, it can have weird side effects.
Problems can happen, when a protocol fails because the Cfd was put into a closed state while another protocol was ongoing. This can for example happen during a rollover. If we trigger a collaborative settlement during rollover, the rollover will fail upon finishing up, because the collaborative settlement has priority (as per the changes in ##1359).
Note: Making collaborative settlement and rollover mutually exclusive would be possible, but then we have to ensure that we actually always record a Completed event for a protocol. At the moment this is not guaranteed, because if the application is restarted mid protocol the protocol actor will be gone and we might never record a failure.

We could solve this by ensuring that we always properly complete a protocol. This could involve some kind of housekeeping task upon startup.

We could also redefine what it means to record failure events. Such kind of events do not necessarily guarantee a 1:1 mapping to a state; i.e. if rollover fails I have to know why it failed to reason about mapping to Open or another state (at the moment it's always Open). But we don't record the reason in the Event. We could also say that upon failure I have to take the previous event history into account to decide what my state it.

I think another part of this problem comes from mapping the events to state in general. We discussed on several occasions that the state model in the projection "should change". I wanted to open a discussion on how we see this evolve in the future.

[thomaseizinger]

When we apply the events in porjection::Cfd we always set a state depending on the event, meaning that the last event basically decides the state. While this sounds good in theory, it can have weird side effects.

You have exactly pin-pointed the problem. What decides the state is the entire history of events, not just the last one.

[thomaseizinger]

I also think that CfdState needs to be massively simplified. I would go as far as saying there is only two actual states: Open and Closed. Everything in-between is not a state we should be exposing.

[da-kami]

What does Closed mean for you? We find a spend transaction in mempool? We have the spend transaction set? The spend transaction was confirmed?

We are already combining Open more and more, but I think for Closed it's harder to define the boundaries.

[thomaseizinger]

What does Closed mean for you?

Hmm, I think the blockchain must have priority. Closed for me means the joint output of lock has been spent into one per taker and maker and is confirmed with what we consider enough confirmations.

Closing is probably everything before:

• Found commit tx in mempool
• Executing collab close protocol
• Broadcasting commit
• CET pending

I think a state transition of Closing -> Open should be okay and expected: A transaction can be dropped from mempool or the blockchain can be re-orged or the collab close protocol can fail.

[da-kami]

One improvement that we could finally action in relation to this is adding a Close action and letting the daemon decide when the user can click close. The UI would then display the button based on the action.

However that still does not help the user understand why the button might not be available in some Open scenarios - but maybe we won't have this problem anymore. Collaborative settlement can be triggered during an ongoing rollover and will have priority now (we just have to make sure that the projection does not keep the cfd Open upon failing a rollover)

[thomaseizinger]

+1 for letting the daemon decide.

The other stuff we don't need to overthink. Combined positions will change that anyway :)