Description
This issue aims to address the implementation of Automatic Eviction of Terminal MultiSig Operations.
The core objective is to: Add automatic eviction of completed ('submitted') and expired ('expired') multi-sig operations from MultiSigEscrowClient's internal operations Map, so long-lived SDK processes coordinating many escrow operations don't accumulate unbounded memory. MultiSigEscrowClient (src/escrow/multisig.ts) stores every operation ever created in private readonly operations = new Map<string, MultiSigOperation>() for the lifetime of the client instance. initMultiSigOperation only ever adds to this Map; nothing in the class ever calls this.operations.delete(...). getMultiSigStatus lazily flips an operation's status to 'expired' when checked past its expiresAt, and submitWhenReady flips it to 'submitted' on success, but a terminal-status operation is never removed — listOperations(escrowId) will keep returning every historical operation for that escrow forever. This is a distinct concern from the cross-process persistence gap already tracked by the #79 spike and #83 (which is about state not surviving a process boundary) — this issue is about state that never gets cleaned up even within one process's lifetime.
By completing this feature, we will ensure that the TrustFlow protocol maintains its high standards for security, usability, and decentralized logic. This issue requires careful attention to the SDK Wrapper architecture and adherence to the existing project conventions.
Component
SDK
Difficulty
🔴 Hard
Tasks
Acceptance Criteria
Estimated Time
2-3 days
Description
This issue aims to address the implementation of Automatic Eviction of Terminal MultiSig Operations.
The core objective is to: Add automatic eviction of completed (
'submitted') and expired ('expired') multi-sig operations fromMultiSigEscrowClient's internaloperationsMap, so long-lived SDK processes coordinating many escrow operations don't accumulate unbounded memory.MultiSigEscrowClient(src/escrow/multisig.ts) stores every operation ever created inprivate readonly operations = new Map<string, MultiSigOperation>()for the lifetime of the client instance.initMultiSigOperationonly ever adds to this Map; nothing in the class ever callsthis.operations.delete(...).getMultiSigStatuslazily flips an operation's status to'expired'when checked past itsexpiresAt, andsubmitWhenReadyflips it to'submitted'on success, but a terminal-status operation is never removed —listOperations(escrowId)will keep returning every historical operation for that escrow forever. This is a distinct concern from the cross-process persistence gap already tracked by the #79 spike and #83 (which is about state not surviving a process boundary) — this issue is about state that never gets cleaned up even within one process's lifetime.By completing this feature, we will ensure that the TrustFlow protocol maintains its high standards for security, usability, and decentralized logic. This issue requires careful attention to the SDK Wrapper architecture and adherence to the existing project conventions.
Component
SDK
Difficulty
🔴 Hard
Tasks
MultiSigOperation/MultiSigOperationStatusinsrc/types/multisig.ts)operationsMapMultiSigEscrowClient.prune()method)listOperationsreflects only retained (non-evicted) operationsAcceptance Criteria
MultiSigEscrowClient's operations Map does not grow without bound in a long-lived processEstimated Time
2-3 days