peer: fix MarkCoopBroadcasted to correctly use local parameter

[darioAnongba]

This commit fixes a bug in chanObserver.MarkCoopBroadcasted where the local parameter was being ignored. The function always passed lntypes.Local to the underlying MarkCoopBroadcasted call, regardless of which party actually initiated the cooperative close.

This caused the channel status to incorrectly include ChanStatusLocalCloseInitiator even on the remote node, resulting in incorrect close_initiator values in RPC responses.

The fix converts the local bool parameter to the appropriate lntypes.ChannelParty before passing it through.

[gemini-code-assist]

Summary of Changes

Hello @darioAnongba, 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 resolves a critical bug in the channel observer's cooperative close broadcast marking mechanism. The issue stemmed from an incorrect handling of the local parameter, which caused the system to misattribute the initiator of a cooperative channel close. By ensuring the correct party is identified, this change prevents misleading channel status reports and inaccurate RPC response data, thereby improving the reliability of channel state management.

Highlights

• Bug Fix: Addressed a bug in chanObserver.MarkCoopBroadcasted where the local boolean parameter was being ignored, always defaulting to lntypes.Local.
• Incorrect Channel Status: The previous behavior led to the ChanStatusLocalCloseInitiator flag being incorrectly set on remote nodes, and erroneous close_initiator values in RPC responses.
• Parameter Conversion: The fix introduces logic to correctly convert the local boolean into the appropriate lntypes.ChannelParty (either Local or Remote) before passing it to the underlying MarkCoopBroadcasted call.

🧠 New Feature in Public Preview: You can now enable Memory 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 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 counter productive. 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.

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.

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 addresses a bug in chanObserver.MarkCoopBroadcasted where the local parameter was disregarded, leading to incorrect channel status updates. The fix correctly translates the boolean local parameter into the appropriate lntypes.ChannelParty, ensuring the correct initiator of a cooperative close is recorded. The change is clear, correct, and well-contained. Excellent work.

[lightninglabs-deploy]

🔴 PR Severity: CRITICAL

Bug fix | 1 file | 7 lines changed

🔴 Critical (1 file)

• peer/chan_observer.go - Fixes bug in cooperative close tracking that incorrectly marks close initiator in channel state persistence

Analysis

This PR is classified as CRITICAL because it modifies code in the peer/* directory, which handles encrypted peer connections and core peer coordination logic.

The specific bug being fixed is in chanObserver.MarkCoopBroadcasted at peer/chan_observer.go:121-123, where the local parameter was being ignored. The function always passed lntypes.Local regardless of which party initiated the cooperative close, causing incorrect ChanStatusLocalCloseInitiator flags and wrong close_initiator values in RPC responses.

While this is a small, surgical fix (7 lines changed), it affects channel state persistence during cooperative closes, which is a critical operation. The bug could lead to incorrect accounting of who initiated channel closes, potentially affecting analytics, dispute tracking, or other downstream systems that rely on accurate close initiator information.

The fix properly converts the boolean parameter to the appropriate lntypes.ChannelParty value before persisting to the database.

Recommendation: This requires expert review to ensure the fix correctly handles both local and remote close initiator cases and that the persisted state is now accurate.

---

_{To override, add a severity-override-{critical,high,medium,low} label.}

[ziggie1984]

Looks good, pending release-note entry

[darioAnongba]

Release note added.

[lightninglabs-deploy]

🔴 PR Severity: CRITICAL

Automated classification | 2 files | 15 lines changed

🔴 Critical (1 file)

• peer/chan_observer.go - Peer connection handling and channel observer logic

🟢 Low (1 file)

• docs/release-notes/release-notes-0.21.0.md - Release notes documentation

Analysis

This PR fixes a bug in the cooperative channel close flow where the local parameter was being ignored in chanObserver.MarkCoopBroadcasted. The function always passed lntypes.Local regardless of which party initiated the close, causing incorrect close_initiator values in RPC responses.

Why CRITICAL:

• The change is in peer/*, which handles peer connection coordination and channel lifecycle management
• This bug affects channel state tracking and could lead to incorrect reporting of which party initiated cooperative closes
• While the fix is small (6 lines), it touches core peer functionality related to channel closure

Review considerations:

• Verify the conversion from bool to lntypes.ChannelParty is correct
• Check that this fixes the incorrect ChanStatusLocalCloseInitiator status issue
• Ensure RPC responses now return correct close_initiator values
• Consider whether any existing channels might have incorrect historical close initiator data

---

_{To override, add a severity-override-{critical,high,medium,low} label.}

[hieblmi]

LGTM!