You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: guard terminal FILLED status from downgrade; reaper re-checks DB status before resolving (PROTO-1201) (#688)
* fix: guard terminal FILLED status from downgrade; reaper re-checks DB status before resolving
Follow-up hardening to #683/#687 (PROTO-1201). Order 0x33e09be0... was filled
on mainnet and recorded FILLED (txHash + settledAmounts) by check-order-status,
but a concurrent GS Reaper run -- whose fill scan predated the fill -- read the
order's used nonce as a cancellation and blindly overwrote the record to
CANCELLED. Two gaps remained:
1. GenericOrdersRepository.updateOrderStatus wrote orderStatus unconditionally,
so any writer could downgrade a terminal FILLED order. Now a non-FILLED
write carries a DynamoDB ConditionExpression (orderStatus <> filled), making
the guard atomic with the write. A ConditionalCheckFailedException is logged
and skipped rather than thrown, so callers don't enter retry loops.
Legitimate transitions (OPEN/INSUFFICIENT_FUNDS -> FILLED, re-writing FILLED
with fill details) are unaffected.
2. The reaper's CHECK_CANCELLED stage validated orders from the run's
GET_OPEN_ORDERS snapshot without re-checking their current DB status. It now
skips any order whose status no longer matches the run's unresolved-status
snapshot (e.g. resolved to FILLED mid-run by the status state machine).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EpJxMZvZepV198FGXBNUwk
* refactor: drop reaper status param for terminal-set guard; simplify repository condition per review
---------
Co-authored-by: Claude <noreply@anthropic.com>
0 commit comments