staticaddr/deposit: separate generic OnError from caller-held rollback events

未关闭
  • 哪里不对？
#1,168 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
冷清
技术栈
go
领域
backend

调研方向

首先跟踪 updateDeposit、lockedEvents 和 TransitionDeposits，然后检查 deposit FSM 的操作 PublishDepositExpirySweepAction 和 WaitForExpirySweepAction。将由调用方持有的回滚事件与通用的 fsm.OnError 分开，使内部生成的错误获取 deposit lock，同时由 manager 驱动的回滚避免重复加锁。当两条路径都能在不依赖错误的锁假设的情况下保留预期状态和 store 更新时，即视为完成。

由索引模型根据 Issue 内容生成。

描述

Problem

The static-address deposit FSM currently treats fsm.OnError as if it always arrives while the caller already holds the deposit lock.

That assumption is not reliable. Some fsm.OnError transitions do come from TransitionDeposits, where the manager locks deposits before sending the event. But deposit FSM actions can also emit fsm.OnError internally. Examples include:

  • PublishDepositExpirySweepAction returning fsm.OnError after expiry sweep publish failures;
  • WaitForExpirySweepAction returning fsm.OnError after notifier or context errors.

Those internal paths originate from the deposit FSM's own block handling, so no external deposit lock is held.

Because fsm.OnError is in lockedEvents, updateDeposit can skip acquiring the deposit lock, call no-lock state mutation helpers, and update the store under an assumption that is false for internally generated errors.

This was discussed during PR #1161: https://github.com/lightninglabs/loop/pull/1161#discussion_r3539803146

The issue appears to predate PR #1161, but that PR touched the surrounding deposit locking/lifecycle code and made the invariant visible.

Potential fix

Do not use the generic fsm.OnError event to also mean "caller-held rollback/unlock to Deposited".

One possible shape:

  • introduce a deposit-specific rollback event, for example OnReleaseDeposit or OnDepositRollback;
  • use that event from manager-driven TransitionDeposits callers that already hold deposit locks and need to move selected deposits back to Deposited;
  • include that specific rollback event in lockedEvents;
  • remove generic fsm.OnError from lockedEvents, so internally generated errors acquire the deposit lock inside updateDeposit;
  • keep fsm.OnError as the generic action-error transition in the deposit FSM, not as an implicit lock-state signal.

That separates event meaning from caller locking context: events sent by TransitionDeposits can still avoid double-locking, while internally generated fsm.OnError paths no longer run no-lock state/store updates without a held deposit lock.

主要语言
Go
星标
593
派生
137
平均合并
2 天 6 小时
30 天内合并 PR
13

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

lightninglabs/loop 的其他 Issue

查看 lightninglabs/loop 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。