Severity: MEDIUM
The hold invoice is settled before the compare-and-set status guard runs, opening a double-settle race.
Where
src/app/release.rs and src/app/admin_settle.rs — the LN settle action executes prior to (or independently of) the atomic status transition that is meant to guard against concurrent handlers acting on the same order.
Problem
Two near-simultaneous release/settle events for the same order can both pass the pre-check, both trigger the settle side effect, and only then contend on the status write. The window is small and usually benign, but it can produce duplicated settlement attempts and confusing state/log output.
Suggested fix
- Perform the atomic status CAS (
... WHERE status = <expected>) first, and only proceed to settle if the CAS affected a row.
- Treat "0 rows updated" as "already handled" and no-op.
Found during the deep review accompanying #803.
Severity: MEDIUM
The hold invoice is settled before the compare-and-set status guard runs, opening a double-settle race.
Where
src/app/release.rsandsrc/app/admin_settle.rs— the LNsettleaction executes prior to (or independently of) the atomic status transition that is meant to guard against concurrent handlers acting on the same order.Problem
Two near-simultaneous release/settle events for the same order can both pass the pre-check, both trigger the settle side effect, and only then contend on the status write. The window is small and usually benign, but it can produce duplicated settlement attempts and confusing state/log output.
Suggested fix
... WHERE status = <expected>) first, and only proceed tosettleif the CAS affected a row.Found during the deep review accompanying #803.