Skip to content

Simplify ChannelUnavailable APIError handling with let-else#4736

Open
Abeeujah wants to merge 2 commits into
lightningdevkit:mainfrom
Abeeujah:let-else
Open

Simplify ChannelUnavailable APIError handling with let-else#4736
Abeeujah wants to merge 2 commits into
lightningdevkit:mainfrom
Abeeujah:let-else

Conversation

@Abeeujah

Copy link
Copy Markdown
Contributor

e9e3060 Fixes the TODO for the error handling.
3d6a879 Fixes the triggered manual_str_repeat lint.

Abeeujah added 2 commits June 22, 2026 12:54
Refactor the nested match statement used during error construction into
a more idiomatic let-else construct (stabilised in Rust 1.65). The
previous implementation required verbose, nested matching to navigate
around borrow checker limitations.

By leveraging let-else alongside chaining unwrap_err on handle_error
Result, we achieve the same teardown logic (dropping state locks)
and error mapping with significantly less boilerplate and nesting.
Clippy errors when a manual implementation of `repeat` is used instead
of the `str::repeat` method, especially for MSRV > `1.16.0`.

Since our MSRV is `1.75.0` and `str::repeat` was stabilized in
`1.16.0`, this commit fixes the three instances where Clippy
triggered the `manual_str_repeat` lint.
@ldk-reviews-bot

ldk-reviews-bot commented Jun 22, 2026

Copy link
Copy Markdown

I've assigned @valentinewallace as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@ldk-claude-review-bot

Copy link
Copy Markdown
Collaborator

No issues found.

Both changes are correct and behavior-preserving:

  • channelmanager.rs:11468-11473 — the let-else refactor is equivalent to the original match. handle_error always returns Err for an Err input (it's a map_err), so .unwrap_err() cannot panic, and res remains owned/usable in the else block since a failed match moves nothing.
  • macro_logger.rs"a".repeat(n) / "\u{1F600}".repeat(n) are semantically identical to the previous iter::repeat(c).take(n).collect(), including the multibyte case.

@Hamza1610 Hamza1610 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test Results: PASS

All tests passed successfully! However, there are a couple of minor warnings to address:

** Redundant Import in channelmanager.rs**
warning: the item Hasher is imported redundantly
--> lightning/src/ln/channelmanager.rs:19832:35
|
177 | use core::hash::{Hash, Hasher};
| ------ the item Hasher is already imported here
19832 | use core::hash::{BuildHasher, Hasher};
| ^^^^^^

Issue: Hasher is imported twice in the same file. Fix: Remove the redundant Hasher from line 19832, keeping only BuildHasher: use core::hash::{BuildHasher};

Overall: Tests pass |Only minor cleanup needed

Image Image

@Hamza1610

Copy link
Copy Markdown

When I was testing I noticed some ignored test. These might be deprecated test that are not in used anymore. I'm suggesting to create a new PR for this. @casey what do you think about that.

@Abeeujah

Copy link
Copy Markdown
Contributor Author

use core::hash::{Hash, Hasher};

Hi @Hamza1610

I appreciate the review! However, the unused import warning is actually unrelated to the changes in this PR. It looks like it was introduced to main in commit a1ad1a3

Given the ongoing Forgejo migration (#4734), it's probably best to avoid scope creep here to keep this PR clean and prevent untracked changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants