Enable recovering in closed state too

[v0d1ch]

Why

I ran into an issue where my funds got locked at the deposit contract after the Head got fanned-out. We could enable recovering also in the closed state so users have better time getting their funds back.

What

• Propagate pendingDeposits map from the OpenState to ClosedState to enable the client input Recover working in both states.
• Update HeadLogic/update function to enable recover in the Closed state too.

[ch1bo]

How about keeping the pending deposits completely outside of the HeadState? AFAIK a deposit is not really tied to a specific head. Consequently the state is independent of whether a head is open or not. The API under which this is available could be an indicator too, it does not involve any head id, right? IIRC that would be GET /deposits and recovering a deposit is DELETE /deposits/<deposit-id>.

[v0d1ch]

Where do you propose we keep this information? HeadLogic deals with HeadState only and has access to Environment also but that is not a proper place to put it either. New data type?

[v0d1ch]

Conversation from slack for the reference:

We drafted a notion of a NodeState in the past, which would contain one or more HeadState (even allowing multi-head node). So as the list of pending deposits is disconnected from any specific head (although they target a head, by id), we could think about keeping them there. So something like
data NodeState tx = NodeState { headState :: HeadState tx, pendingDeposits :: [Deposit tx], lastEventId :: Last EventId }

[noonio]

I like this; I'm tempted not to over-complicate it and just leave @ch1bo 's suggestion to future work; especially that I do think it's reasonable to consider deposit's basically directed at a specific head, as mentioned.

[ch1bo]

I like this; I'm tempted not to over-complicate it and just leave @ch1bo 's suggestion to future work; especially that I do think it's reasonable to consider deposit's basically directed at a specific head, as mentioned.

If we do not keep the deposits outside of HeadState I would argue that we need to add them to all variants of the sum type. Because the node could already see the head finalized or even adopted a new head altogether. If we make it convenient for users to list and recover deposits..it should be about all deposit seen, no matter which head we track.

An overall alternative would be to not provide that convenience at all and outsource the listing and recovering to something completely different. For example the explorer and the hydra-tx binary/library. This has other complexities though.