Skip to content

Linting: Disallow unwraps, replace with expect or error propagation#868

Open
tnull wants to merge 12 commits intolightningdevkit:mainfrom
tnull:2026-04-disallow-unwrap
Open

Linting: Disallow unwraps, replace with expect or error propagation#868
tnull wants to merge 12 commits intolightningdevkit:mainfrom
tnull:2026-04-disallow-unwrap

Conversation

@tnull
Copy link
Copy Markdown
Collaborator

@tnull tnull commented Apr 3, 2026

For the longest time we wanted to enforce clear rules around unwrap use. Here we finally do that:

  1. We switch all Mutex/RwLock locking to Ext helpers that avoid the unwrap and are shorter, reducing clutter in code
  2. We switch over any other unwraps to use expects, providing clear rationale why they are deemed unreachable
  3. For some cases we switch to error propagation. While they are not reachable, it seems simpler/cleaner that way.
  4. We ban the introduction of new unwraps through clippy in CI (in non-test/documentation code, that is)

tnull added 11 commits April 3, 2026 11:55
Introduce a small lock helper module so mutex and rwlock access can use a single naming convention instead of repeating direct locking at every call site.

Co-Authored-By: HAL 9000
Switch the codebase over to the new lock helper names so lock poisoning behavior is centralized and the call sites stay shorter and more consistent.

Co-Authored-By: HAL 9000
Document the internal invariants behind the remaining non-lock unwrap sites so panic paths explain why they should be unreachable, while keeping the known reachable cases explicit for later handling.

Co-Authored-By: HAL 9000
Log and skip runtime listener failures instead of panicking when accepting inbound connections or converting accepted sockets. These errors can happen in normal operation, so keeping the node running is safer than treating them as unreachable.

Co-Authored-By: HAL 9000
Replace the success-path unwrap on payment amounts with an expect that explains why outbound payments must already have a recorded amount by the time LDK reports them as sent.

Co-Authored-By: HAL 9000
Replace the pending-channel unwrap with an expect that records why supported LDK Node state should always include the former temporary channel id. Older rust-lightning state could omit it, but LDK Node never shipped before that field existed.

Co-Authored-By: HAL 9000
Replace the remaining channel-details unwraps with expects that point to the supported LDK Node upgrade boundary. The missing fields only occur in rust-lightning versions older than the ldk-node v0.1.0 baseline.

Co-Authored-By: HAL 9000
Replace the user_version query unwrap with normal io::Error propagation so database initialization failures are reported cleanly instead of panicking.

Co-Authored-By: HAL 9000
Replace the Tokio runtime builder unwrap with io::Error propagation so VSS startup failures surface through the constructor instead of panicking.

Co-Authored-By: HAL 9000
Use a zero-millisecond fallback for elapsed-time logging so clock adjustments do not panic the chain polling loop.

Co-Authored-By: HAL 9000
Return Esplora client construction failures through build-time error handling instead of panicking so invalid headers or reqwest setup errors fail node construction cleanly.

Co-Authored-By: HAL 9000
@tnull tnull requested a review from joostjager April 3, 2026 10:45
@ldk-reviews-bot
Copy link
Copy Markdown

ldk-reviews-bot commented Apr 3, 2026

👋 Thanks for assigning @joostjager 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.

Fail library clippy runs when new unwrap calls are introduced so the unwrap policy stays enforced without pulling tests, benches, or docs into the restriction.

Co-Authored-By: HAL 9000
@tnull tnull force-pushed the 2026-04-disallow-unwrap branch from a05b2b6 to 2eb9f09 Compare April 3, 2026 11:10
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.

2 participants