feat: single-owner registry for per-trade subscriptions - #407
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughThe PR adds a centralized registry for per-trade daemon-message subscriptions. Watchers now use single-owner claims, stable subscription IDs, lease-aware rearming, and targeted teardown. Tests cover ownership, pending requests, subscription IDs, and shutdown behavior. ChangesPer-trade subscription lifecycle
Priority: ⬇️ Low Estimated code review effort: 4 (Complex) | ~45 minutes Merge Risk: ⚪ Minimal · up to Per-trade daemon subscriptions now remain single-owner across repeated setup while preserving pending requests during rearming and cleaning up on shutdown or closed channels. No concrete current-head merge-blocking risk remains. Sequence Diagram(s)sequenceDiagram
participant DaemonWatcher
participant SubscriptionRegistry
participant RelayClient
participant PendingRequests
DaemonWatcher->>SubscriptionRegistry: try_claim(trade_key)
SubscriptionRegistry-->>DaemonWatcher: owner or rearm signal
DaemonWatcher->>RelayClient: subscribe with stable subscription ID
DaemonWatcher->>SubscriptionRegistry: teardown_or_rearm(trade_key)
alt Lease rearmed
SubscriptionRegistry-->>DaemonWatcher: continue watcher
else Teardown
SubscriptionRegistry->>RelayClient: unsubscribe subscription ID
SubscriptionRegistry->>PendingRequests: purge trade request
end
DaemonWatcher->>SubscriptionRegistry: teardown(trade_key) on shutdown
SubscriptionRegistry->>RelayClient: unconditional unsubscribe
SubscriptionRegistry->>PendingRequests: purge trade request
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. A rabbit guards one listening thread Comment |
|
This branch conflicts with What to do on rebase:
|
Close #325
Every per-trade watcher's exit path runs a destructive pair —
unsubscribeon its deterministic id pluspurge_pending_request— unconditionally. Today that is safe only by accident: every caller ofsubscribe_daemon_messagesderives a fresh trade key first, so two watchers can never share an id. The restore apply (#218) breaks that invariant by design: it must be idempotent, and re-applying a snapshot re-arms watchers for trade keys that already have one. The older watcher's exit would then kill the newer one's live subscription and purge its pending record — surfacing asNoDaemonResponseon an order the daemon actually accepted, during a restore.Change
New
rust/src/nostr/subscriptions.rs— a single-owner registry for the per-trade subscription lifecycle, following the repo's ownACTIVE_CHATSprecedent (messages.rs) rather than importing Mostrix's shape:try_claimadmits exactly one owner per trade key. A second claim bounces — the live subscription and its pending record stay untouched.ACTIVE_CHATSreleases before unsubscribing and leaves exactly that window open; this module documents why not to copy that ordering.daemon_message_subscription_idmoves into the module (id + ownership together, in line with #120).subscribe_single_orderis out of scope: single caller, not on the #218 path.Summary by CodeRabbit
Bug Fixes
Tests