Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@louisinger
Copy link
Collaborator

@louisinger louisinger commented Nov 27, 2025

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

  • New Features
    • Added cancellation support for sweep operations, allowing tasks to be interrupted gracefully when needed.

✏️ Tip: You can customize this high-level summary in your review settings.

@louisinger louisinger requested a review from altafan November 27, 2025 14:49
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Nov 27, 2025

Walkthrough

The 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

Cohort / File(s) Summary
Sweeper cancellation support
internal/core/application/sweeper.go
Added ctx field to sweeper struct, initialized during start, and integrated context cancellation check in BIP68 final retry loop to enable graceful shutdown signaling.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

  • Verify the context field is properly initialized and managed across the sweeper lifecycle
  • Confirm the cancellation check in the BIP68 final retry loop correctly interrupts the sweep flow without leaving resources in an inconsistent state

Possibly related PRs

  • Move sweeper.start in go routine #763: Directly related—modifies sweeper cancellation handling by wiring a context into sweeper start and running shutdown via a cancellable goroutine, complementing the context cancellation checks introduced here.
  • sweeper: fix retry on non-bip68-final  #758: Modifies the same BIP68 final retry logic in sweeper.go, affecting error matching and propagation alongside the cancellation changes in this PR.

Suggested reviewers

  • altafan

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'cancel BIP68-non-final retry on sweeper stop' directly and specifically describes the main change: storing the cancellation context and using it to cancel a specific retry loop when the sweeper stops.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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 accessing s.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

📥 Commits

Reviewing files that changed from the base of the PR and between a337c9c and e06ecaf.

📒 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.

@altafan altafan merged commit 0c49bf7 into arkade-os:master Nov 27, 2025
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants