-
Notifications
You must be signed in to change notification settings - Fork 1
Add closed channels #472
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add closed channels #472
Conversation
Pull Request Review: Add Closed ChannelsSummaryThis PR adds functionality to track and display closed Lightning channels in the UI. The implementation introduces a channel cache mechanism, persists closed channel data, and displays closed channels with proper visual differentiation. Code Quality & Best Practices ✅Strengths:
Suggestions:
Potential Bugs & Issues
|
PR Review: Add Closed ChannelsOverviewThis PR adds functionality to track and display closed Lightning channels. The implementation includes persistence of closed channel data, UI updates to show closed channels in the connections list, and proper state management. Code Quality & Best PracticesStrengths:
Areas for Improvement:
Potential Bugs
Performance Considerations
Security ConcernsNo significant security issues found. The code properly:
Minor consideration:
Test CoverageMissing Tests:
Recommendations:
Architecture & DesignPositive:
Suggestions:
Additional Notes
SummaryThis is a well-implemented feature with good code quality. The main concerns are:
The code follows the project's patterns and conventions well. With the suggested improvements, this will be a solid addition to the codebase. Overall Assessment: Approve with minor suggestions for improvement. 🤖 Generated with Claude Code |
jvsena42
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested:
- Close channel
- Open channel
- Reset and restore
- Check channel list
ovitrif
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK.
Code is ok with the exception that it violates the otherwise esablished pattern about LightingService, in that LightningService acts more like a wrapper for ldk-node bindings.
Now we're introducing state to it, and we are inter-connecting it with more code components, a practice that was avoided until now.
My suggestion is to move the specific logic which orchestrates multiple code components and manages state to LightningRepo; where we did most if such work.
So the data flow up would be:
ViewModel (UI) → Repository (Domain) → LightningService (bridge to ldk-node bindings)
|
Tested:
|
|
Architectural change referenced here can be done later (it's not critical to implementation): |
Track channels once closed and show them in the list of channels.