rpcserver: filter backup subscription events

[ziggie1984]

ChannelUpdate events where introduced in #10543

Change Description

Channel update notifications now flow through ChannelNotifier, so the
existing SubscribeChannelBackups deny-list started treating commitment
updates as backup-relevant events. That makes the backup stream emit on every
channel update, which is much noisier than the lifecycle events this stream
historically tracked.

This PR switches SubscribeChannelBackups to an allow-list of lifecycle events
that should trigger a backup snapshot. It also documents that ChannelNotifier
includes higher-frequency channel state updates, so lifecycle-only consumers
should explicitly filter for the event types they consume.

Steps to Test

go test ./channelnotifier
go test .

[gemini-code-assist]

Summary of Changes

Hello, 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 refines the event subscription logic for channel backups to reduce unnecessary notifications. By switching from a deny-list to an explicit allow-list of lifecycle events, the system avoids triggering backup snapshots on every commitment update, ensuring the stream remains focused on relevant channel lifecycle changes.

Highlights

• Event Filtering: Updated the SubscribeChannelBackups RPC method to use an allow-list for channel lifecycle events, preventing excessive noise from high-frequency commitment updates.
• Documentation: Added documentation to ChannelNotifier.SubscribeChannelEvents to clarify that it includes both lifecycle and state update events, advising consumers to filter as needed.

New Features

🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

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 by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

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 pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the 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 may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. 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]

Code Review

This pull request updates the documentation for channel event subscriptions to warn about high-frequency updates and refactors the backup subscription logic to use an allow-list for lifecycle events. Feedback was provided regarding a potential infinite loop in the event processing logic; if the event channel closes, the new default case would continuously execute, so an explicit check for nil values is required to terminate the loop.

[github-actions]

PR Severity: CRITICAL. rpcserver.go is explicitly CRITICAL (core server coordination). channelnotifier/channelnotifier.go is MEDIUM. Highest severity wins. 2 files, 31 lines - no severity bump applied. <!-- pr-severity-bot -->

[ziggie1984]

A note on test coverage: I considered adding a dedicated unit test for the event filter but decided against it. The original regression came from a new event type being added upstream in ChannelNotifier without the deny-list in rpcserver.go being updated — a class of bug that a predicate test can't catch, since the test would just enumerate the same set the predicate already lists.

Two things in this PR address that more directly:

1. The switch is now an allow-list, so any future event type added to ChannelNotifier is excluded by default rather than leaking through silently.
2. The new doc comment on SubscribeChannelEvents flags the high-frequency nature of the stream so other lifecycle-only consumers don't fall into the same trap.

A reflection-based test enumerating all channelnotifier event types would be the only thing that could mechanically catch this class of bug, but that feels like overkill for a 5-case switch. The existing itest in lnd_channel_backup_test.go covers the happy path; if we want stronger coverage we could extend it later to assert no spurious emits during a payment, but I don't think it should block this fix.

[yyforyongyu]

LGTM🦺

[bitromortac]

Thanks, LGTM 🎉

[bitromortac]

Seems like we could enhance the backup mechanism a bit by also writing a backup once we update the commitment transaction. Otherwise the close transaction is outdated for sure, but not sure about the write frequency tradeoff.

[github-actions]

Successfully created backport PR for v0.21.x-branch:

• [v0.21.x-branch] Backport #10821: rpcserver: filter backup subscription events #10825