-
Notifications
You must be signed in to change notification settings - Fork 54
cancel BIP68-non-final retry on sweeper stop #839
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughThe sweeper struct now stores a context field that is initialized during start. A cancellation check is introduced in the BIP68 final retry loop within the batch sweep task flow, allowing early exit when the context is canceled. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 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. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
internal/core/application/sweeper.go (1)
61-62: Good! Context stored for cancellation handling.The context is properly captured and will be used to cancel the BIP68 retry loop when the sweeper stops.
Optional: Consider thread-safe access to context field.
While unlikely to cause issues given the typical usage pattern (start called once at initialization), you could add defensive synchronization for the ctx field to make the code more robust:
type sweeper struct { wallet ports.WalletService repoManager ports.RepoManager builder ports.TxBuilder scheduler ports.SchedulerService noteUriPrefix string // cache of scheduled tasks, avoid scheduling the same sweep event multiple times locker *sync.Mutex // TODO move the scheduled task map to LiveStore port scheduledTasks map[string]struct{} + ctxLocker *sync.RWMutex ctx context.Context }Then use
s.ctxLocker.Lock()/s.ctxLocker.RLock()when accessings.ctx. However, this is purely defensive since the current implementation should work fine in practice.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
internal/core/application/sweeper.go(3 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: louisinger
Repo: arkade-os/arkd PR: 686
File: internal/core/application/fraud.go:47-61
Timestamp: 2025-08-28T08:21:01.170Z
Learning: In reactToFraud function in internal/core/application/fraud.go, the goroutine that waits for confirmation and schedules checkpoint sweep should use context.Background() instead of the request context, as this is intentional design to decouple the checkpoint sweep scheduling from the request lifetime.
📚 Learning: 2025-08-28T08:21:01.170Z
Learnt from: louisinger
Repo: arkade-os/arkd PR: 686
File: internal/core/application/fraud.go:47-61
Timestamp: 2025-08-28T08:21:01.170Z
Learning: In reactToFraud function in internal/core/application/fraud.go, the goroutine that waits for confirmation and schedules checkpoint sweep should use context.Background() instead of the request context, as this is intentional design to decouple the checkpoint sweep scheduling from the request lifetime.
Applied to files:
internal/core/application/sweeper.go
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: integration tests
- GitHub Check: Build and Scan
- GitHub Check: unit tests
🔇 Additional comments (3)
internal/core/application/sweeper.go (3)
44-44: LGTM! Context field added for lifecycle management.The new context field enables cancellation of long-running operations, which aligns with the PR objective.
53-53: LGTM! Proper initialization.The context is correctly initialized to nil in the constructor and will be set when start() is called.
582-586: Excellent! Cancellation check properly implements the PR objective.The select statement correctly checks for context cancellation in the BIP68-non-final retry loop, allowing graceful termination when the sweeper is stopped. This prevents the retry loop from continuing indefinitely after shutdown is initiated.
Keep in memory the cancellable context passed to
start()and use it to cancel BIP68-non-final retry loop.@altafan please review
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.