itest: RegisterSpendNtfn detects reorgs #10083

starius · 2025-07-16T02:55:43Z

Change Description

Added itest "reorg_notifications" which tests that RegisterSpendNtfn behaves as expected during a reorg. A reorg notification is produced after a reorg affects the block which has produced a spending notification for this registration.

Steps to Test

make itest icase='reorg_notifications'
make itest icase='reorg_notifications' backend=btcd
make itest icase='reorg_notifications' backend=neutrino

Pull Request Checklist

Testing

Your PR passes all CI checks.
Tests covering the positive and negative (error paths) are included.
Bug fixes contain tests triggering the bug to prevent regressions.

Code Style and Documentation

The change is not insubstantial. Typo fixes are not accepted to fight bot spam.
The change obeys the Code Documentation and Commenting guidelines, and lines wrap at 80.
Commits follow the Ideal Git Commit Structure.
Any new logging statements use an appropriate subsystem and logging level.
Any new lncli commands have appropriate tags in the comments for the rpc in the proto file.
There is a change description in the release notes, or [skip ci] in the commit message for small changes.

📝 Please see our Contribution Guidelines for further guidance.

gemini-code-assist

Summary of Changes

Hello @starius, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a crucial integration test to validate the robustness of the RegisterSpendNtfn RPC in handling blockchain reorgs. The new test case meticulously simulates a reorg event to ensure that clients watching for spending notifications are correctly informed when a confirmed transaction is invalidated and potentially replaced by an alternative transaction on the new chain. This enhances the reliability of chain monitoring within the system.

Highlights

New Integration Test: I've added a new integration test, testReorgNotifications, to verify the behavior of the RegisterSpendNtfn RPC during blockchain reorgs. This test ensures that the system correctly issues reorg notifications when a previously confirmed spending transaction is unconfirmed due to a chain reorganization.
Reorg Notification Verification: The test specifically simulates a scenario where an output is spent by one transaction (tx2b), which is then confirmed. After receiving the spending notification, a reorg is triggered that unconfirms tx2b. The test then asserts that a reorg notification is received by the RegisterSpendNtfn client.
Alternative Spending Confirmation: Following the reorg and the reorg notification, the test confirms an alternative transaction (tx2a) that also spends the same output. It then verifies that a new spending notification is correctly issued for this newly confirmed transaction.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist · 2025-07-16T02:57:51Z

Warning

Gemini encountered an error creating the review. You can try again by commenting /gemini review.

Abdulkbk · 2025-07-21T22:34:11Z

/gemini review

gemini-code-assist

Code Review

The code changes introduce an integration test to verify that RegisterSpendNtfn behaves as expected during a reorg. The test logic is sound and covers the intended scenario well. I've suggested a refactoring to improve the test's readability and maintainability by reducing duplicated code. I've also pointed out some lines exceeding the 80-character limit.

itest/lnd_misc_test.go

gemini-code-assist · 2025-07-21T22:36:45Z

itest/lnd_misc_test.go

+	go func() {
+		spendMsg, err := spendClient.Recv()
+		require.NoError(ht, err)
+		spendDetails := spendMsg.GetSpend()
+		require.NotNil(ht, spendDetails)
+		require.Equal(ht, txid2b[:], spendDetails.SpendingTxHash)
+		close(spendReceived)
+	}()


Consider using a helper function to reduce code duplication for receiving notifications. This will improve readability and maintainability.

I agree with Gemini. I think we can extract this logic since it is being used 3 times, into a method that returns a SpendEvent (without the additional checks), then perform additional checks, such as require.NotNil(ht, spendDetails), after calling the method.

I factored out the logic of receiving and waiting to function receiveSpendNotification:

// receiveSpendNotification tries to receive a spend notification from a spend // client until the context expires. func receiveSpendNotification(ctx context.Context, spendClient rpc.SpendClient) (*chainrpc.SpendEvent, error) {

itest/lnd_misc_test.go

bhandras

Nice addition! LGTM 🎉

bhandras · 2025-07-22T13:01:07Z

itest/lnd_misc_test.go

+		// startHeight -1 means include only unconfirmed.
+		StartHeight: -1,
+	}
+	var tx2aLnrpc *lnrpc.Transaction


nit: imo readability would improve with a few added new lines. Right now code blocks feel a bit too tight.

Added few new lines.

Abdulkbk

Nice 👌, I left a few questions/suggestions.

Abdulkbk · 2025-07-23T21:03:00Z

itest/lnd_misc_test.go

+	// Make sure RegisterSpendNtfn noticed the spending. Give 10s to receive
+	// the notification.
+	spendReceived := make(chan struct{})
+	go func() {


I think if any error occurs inside this goroutine, it will panic, and the main test thread will hang without properly handling/reporting the error until the 10s timeout expires. Maybe we should consider creating an errChan to properly report any issues?

I moved the goroutine to function receiveSpendNotification. All the checks are done outside of the function (and the goroutine), so now it is safe in case of a failure.

Abdulkbk · 2025-07-23T21:08:04Z

itest/lnd_misc_test.go

+		close(spendReceived)
+	}()
+	select {
+	case <-time.After(10 * time.Second):


A 10s timeout might be insufficient and will likely cause flakiness at times, especially under system load or when the backend is slow. Perhaps a better alternative is to use wait.DefaultTimeout, which uses different values based on platform, although I don't think it solves the problem entirely.

Thank you! I used wait.DefaultTimeout

Abdulkbk · 2025-07-23T21:31:03Z

itest/lnd_misc_test.go

+	go func() {
+		spendMsg, err := spendClient.Recv()
+		require.NoError(ht, err)
+		spendDetails := spendMsg.GetSpend()
+		require.NotNil(ht, spendDetails)
+		require.Equal(ht, txid2b[:], spendDetails.SpendingTxHash)
+		close(spendReceived)
+	}()


I agree with Gemini. I think we can extract this logic since it is being used 3 times, into a method that returns a SpendEvent (without the additional checks), then perform additional checks, such as require.NotNil(ht, spendDetails), after calling the method.

Abdulkbk

LGTM 🚀

Abdulkbk · 2025-07-28T20:35:14Z

itest/lnd_misc_test.go

+
+// receiveSpendNotification tries to receive a spend notification from a spend
+// client until the context expires.
+func receiveSpendNotification(ctx context.Context,


nit: Maybe since this helper is specific to testReorgNotifications, we should move there?

Thanks! I moved the function inside.

Added itest "reorg_notifications" which tests that RegisterSpendNtfn behaves as expected during a reorg. A reorg notification is produced after a reorg affects the block which has produced a spending notification for this registration.

gemini-code-assist bot reviewed Jul 16, 2025

View reviewed changes

starius force-pushed the reorg-notif-itest3 branch from cc44eb9 to 7c14269 Compare July 16, 2025 03:10

starius added the no-changelog label Jul 16, 2025

starius force-pushed the reorg-notif-itest3 branch from 7c14269 to 2e214d6 Compare July 16, 2025 03:36

starius marked this pull request as ready for review July 16, 2025 04:16

gemini-code-assist bot reviewed Jul 21, 2025

View reviewed changes

starius mentioned this pull request Jul 22, 2025

sweepbatcher: fix reorg detection lightninglabs/loop#975

Merged

1 task

bhandras approved these changes Jul 22, 2025

View reviewed changes

Abdulkbk reviewed Jul 23, 2025

View reviewed changes

starius force-pushed the reorg-notif-itest3 branch from 2e214d6 to 8dc3f97 Compare July 24, 2025 03:57

starius self-assigned this Jul 24, 2025

saubyk added this to lnd v0.20 Jul 24, 2025

saubyk moved this to In review in lnd v0.20 Jul 24, 2025

Abdulkbk approved these changes Jul 28, 2025

View reviewed changes

itest: RegisterSpendNtfn detects reorgs

8723113

Added itest "reorg_notifications" which tests that RegisterSpendNtfn behaves as expected during a reorg. A reorg notification is produced after a reorg affects the block which has produced a spending notification for this registration.

starius force-pushed the reorg-notif-itest3 branch from 8dc3f97 to 8723113 Compare July 28, 2025 23:19

guggero approved these changes Jul 29, 2025

View reviewed changes

guggero merged commit 13cec7d into lightningnetwork:master Jul 29, 2025
36 of 38 checks passed

github-project-automation bot moved this from In review to Done in lnd v0.20 Jul 29, 2025

itest: RegisterSpendNtfn detects reorgs #10083

itest: RegisterSpendNtfn detects reorgs #10083

Conversation

starius commented Jul 16, 2025

Change Description

Steps to Test

Pull Request Checklist

Testing

Code Style and Documentation

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot commented Jul 16, 2025

Uh oh!

Abdulkbk commented Jul 21, 2025

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

gemini-code-assist bot Jul 21, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bhandras left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Abdulkbk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Abdulkbk Jul 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Abdulkbk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Abdulkbk Jul 23, 2025 •

edited

Loading