Repository navigation
Enable recovering in closed state too #1812
Description
Activity
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 beGET /depositsand recovering a deposit isDELETE /deposits/<deposit-id>.Where do you propose we keep this information? HeadLogic deals with
HeadStateonly and has access toEnvironmentalso but that is not a proper place to put it either. New data type?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 }Reacted by NoonI 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.
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
HeadStateI 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-txbinary/library. This has other complexities though.- addedamber ⚠️Medium complexity or partly unclear featureMedium complexity or partly unclear feature
on May 13, 2025 12 remaining items
- removedamber ⚠️Medium complexity or partly unclear featureMedium complexity or partly unclear feature
on Sep 10, 2025 - linked a pull request that will close this issueFollow up: deposit recovering in all states #2256
on Sep 12, 2025 - linked a pull request that will close this issueFollow up: deposit selection order for ReqSn #2263
on Sep 17, 2025 - moved this from In progress 🕐 to Triage 🏥 in ☕ Hydra Team Work
on Sep 18, 2025 - moved this from In progress 🕐 to Done ✔ in ☕ Hydra Team Work
on Sep 23, 2025 - modified the milestones: 0.23.0, Resolve big known problem UX improvements, marketing initiatives (MS 6.5)
on Nov 7, 2025
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone ✔
- StatusShow more project fields2025 Q4
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
pendingDepositsmap from theOpenStatetoClosedStateto enable the client inputRecoverworking in both states.HeadLogic/updatefunction to enable recover in theClosedstate too.