Delay shutdown when payout transaction broadcasts are pending#7593
Open
alvasw wants to merge 1 commit intobisq-network:masterfrom
Open
Delay shutdown when payout transaction broadcasts are pending#7593alvasw wants to merge 1 commit intobisq-network:masterfrom
alvasw wants to merge 1 commit intobisq-network:masterfrom
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review infoConfiguration used: defaults Review profile: CHILL Plan: Pro 📒 Files selected for processing (5)
🚧 Files skipped from review as they are similar to previous changes (4)
📝 WalkthroughWalkthroughAdds a ShutdownDelayer utility with a Clock abstraction to track and wait up to 2 seconds for pending payment-received messages during shutdown; integrates a BlockingClock at startup, reports pending messages from seller payment flow, and invokes the wait during application shutdown. Changes
Sequence DiagramsequenceDiagram
participant Seller as SellerStep3View
participant ShutDown as ShutdownDelayer
participant App as BisqApp
participant Clock as BlockingClock
rect rgba(100,150,200,0.5)
Note over Seller,ShutDown: Payment release flow
Seller->>ShutDown: reportPendingPaymentReceivedMessage()
ShutDown->>ShutDown: pending++
Seller->>App: onFiatPaymentReceived(callback -> reportPaymentReceivedMessageSent)
App-->>Seller: async completion
Seller->>ShutDown: reportPaymentReceivedMessageSent()
ShutDown->>ShutDown: pending--
end
rect rgba(200,100,100,0.5)
Note over App,Clock: Shutdown sequence
App->>ShutDown: maybeWaitForPendingMessagesToBePublished()
ShutDown->>Clock: getTimeInMillis()
Clock-->>ShutDown: currentTime
loop while pending > 0 and before deadline
ShutDown->>Clock: waitForMillis(200)
Clock->>Clock: sleep(200)
end
ShutDown-->>App: wait complete (or timeout)
App->>App: continue shutdown
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
core/src/main/java/bisq/core/app/ShutdownDelayer.java (2)
42-44: Guard against pending counter underflow.If
reportPaymentReceivedMessageSent()is called more times than the pending report, the counter can go negative and skip waits. Clamping to zero avoids this drift.Suggested change
public static void reportPaymentReceivedMessageSent() { - pendingPaymentReceivedMessages.decrementAndGet(); + pendingPaymentReceivedMessages.updateAndGet(value -> Math.max(0, value - 1)); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@core/src/main/java/bisq/core/app/ShutdownDelayer.java` around lines 42 - 44, reportPaymentReceivedMessageSent currently decrements pendingPaymentReceivedMessages unconditionally which can drive the counter negative; change the implementation in ShutdownDelayer.reportPaymentReceivedMessageSent to clamp at zero instead of allowing underflow by atomically updating pendingPaymentReceivedMessages (e.g., using getAndUpdate/updateAndGet or a CAS loop) so the counter only decrements when > 0 and remains 0 otherwise, preserving thread safety and preventing negative counts.
35-36: Provide a default Clock to avoid null usage.If
maybeWaitForPendingMessagesToBePublished()is called before a clock is injected,clock.getTimeInMillis()will NPE. A defensive default keeps behavior unchanged while making the utility safer.Suggested change
- `@Setter` - private static Clock clock; + `@Setter` + private static Clock clock = new BlockingClock();🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@core/src/main/java/bisq/core/app/ShutdownDelayer.java` around lines 35 - 36, The static Clock field in ShutdownDelayer can be null and cause an NPE when maybeWaitForPendingMessagesToBePublished() calls clock.getTimeInMillis(); initialize the static field with a sensible default clock instance (the project's default/system clock implementation) so clock is never null, and keep the `@Setter` to allow injection; update ShutdownDelayer's private static Clock clock declaration to assign that default (ensuring behavior and tests remain unchanged).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@core/src/test/java/bisq/core/app/ShutdownDelayerTests.java`:
- Around line 40-56: The test increments ShutdownDelayer's static pending
counter and doesn't reset it, causing order-dependent flakiness; modify
delayTest to restore isolation by resetting the counter before and/or after the
test: add a call to a reset method on ShutdownDelayer (e.g.
ShutdownDelayer.resetPendingCount()) in delayTest (or create that method if it
doesn't exist) which sets the internal static pending counter to 0, ensuring
reportPendingPaymentReceivedMessage() calls in delayTest don't affect
noDelayTest.
---
Nitpick comments:
In `@core/src/main/java/bisq/core/app/ShutdownDelayer.java`:
- Around line 42-44: reportPaymentReceivedMessageSent currently decrements
pendingPaymentReceivedMessages unconditionally which can drive the counter
negative; change the implementation in
ShutdownDelayer.reportPaymentReceivedMessageSent to clamp at zero instead of
allowing underflow by atomically updating pendingPaymentReceivedMessages (e.g.,
using getAndUpdate/updateAndGet or a CAS loop) so the counter only decrements
when > 0 and remains 0 otherwise, preserving thread safety and preventing
negative counts.
- Around line 35-36: The static Clock field in ShutdownDelayer can be null and
cause an NPE when maybeWaitForPendingMessagesToBePublished() calls
clock.getTimeInMillis(); initialize the static field with a sensible default
clock instance (the project's default/system clock implementation) so clock is
never null, and keep the `@Setter` to allow injection; update ShutdownDelayer's
private static Clock clock declaration to assign that default (ensuring behavior
and tests remain unchanged).
ℹ️ Review info
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
core/src/main/java/bisq/core/app/BisqExecutable.javacore/src/main/java/bisq/core/app/ShutdownDelayer.javacore/src/test/java/bisq/core/app/ShutdownDelayerTests.javadesktop/src/main/java/bisq/desktop/app/BisqApp.javadesktop/src/main/java/bisq/desktop/main/portfolio/pendingtrades/steps/seller/SellerStep3View.java
A support team member reported an issue where sellers confirm receipt of payment, but the payout transaction is not broadcasted because they close Bisq before the transaction is broadcasted. To address this, we now check for pending payout transaction broadcasts during shutdown and delay the shutdown if necessary.
alvasw
force-pushed
the
delay_shutdown_confirm_payment_received
branch
from
7b5628f to
c819f4d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A support team member reported an issue where sellers confirm receipt of payment, but the payout transaction is not broadcasted because they close Bisq before the transaction is broadcasted.
To address this, we now check for pending payout transaction broadcasts during shutdown and delay the shutdown if necessary.
Summary by CodeRabbit
New Features
Tests