(1/3) Minor error code fixes #3699
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This failure code isn't used anywhere in the codebase and is not defined in BOLT 04.
|
I've assigned @valentinewallace as a reviewer! |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3699 +/- ##
==========================================
- Coverage 89.17% 89.15% -0.02%
==========================================
Files 155 155
Lines 121023 121023
Branches 121023 121023
==========================================
- Hits 107926 107904 -22
- Misses 10447 10461 +14
- Partials 2650 2658 +8 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Pushed fixup for incorrect code for |
Realm is no longer specified in BOLT04, use the specified version error instead.
As is, we're returning an `invalid_onion_blinding` error with no associated data, because the calling code does not attach any data when we have a `OnionDecodeErr::Relay` error. This is arguably not the correct error code anyway, as described below, so this commit updates it to `invalid_onion_payload` which does not require additional error data. In this case, we have received a trampoline payload which we believe should contain details of the next trampoline hop. This information is missing, so we've received an invalid payload. When a blinding point point is present in the payload, we're also the introduction node. BOLT04 indicates that if this `current_path_key` is present and we are the final hop we should return a regular error (rather than using `invalid_onion_blinding` when you're the the final hop). Before this commit, this code was considering our node to be non-final and returning an error accordingly. Our role as the final hop is ambiguous here - we are the final hop in the sphinx packet, but the trampoline packet implies that there should be more hops to come. Given that the trampoline packet is invalid, we defer to our position in the sphinx packet and send back an invalid payload error instead.
Although the specification allows an all-zero sha256_of_onion for invalid_onion_blinding errors, it still requires that the value is set.
valentinewallace
approved these changes
Apr 3, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR pulls a few trivial commits out of #3601 which deal with error code handling unrelated to the larger refactor.
Opening this up in a separate PR because it makes a change to one of the trampoline error codes that is a little spec-ambiguous, originally pointed out here.