Skip to content

Return "Temporary Channel Failure" for offline peer #6803

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

Conversation

C-Otto
Copy link
Contributor

@C-Otto C-Otto commented Aug 6, 2022

Change Description

This fixes #6603. If a forwarding request cannot be processed because the next hop currently is offline, without this patch lnd returns a permanent "unknown next peer" error. Instead, if the requested channel is known, with this patch lnd returns a "temporary channel failure".

Steps to Test

Send forwarding request that should go out through an inactive channel (peer is offline).

Pull Request Checklist

Testing

  • Your PR passes all CI checks.
  • Tests covering the positive and negative (error paths) are included.
  • Bug fixes contain tests triggering the bug to prevent regressions.

Code Style and Documentation

📝 Please see our Contribution Guidelines for further guidance.

C-Otto added 2 commits August 7, 2022 01:37
Only return a permanent "unknown next peer" error if we are unable
to find the channel link. In other cases, especially if the peer
is just offline, return a "temporary channel failure" so that future
retries are encouraged.

fixes lightningnetwork#6603
@C-Otto C-Otto force-pushed the temporary-channel-failure-for-offline-peer branch from fe9c281 to bf30fcb Compare August 6, 2022 23:47
@C-Otto C-Otto marked this pull request as ready for review August 6, 2022 23:56
@@ -851,7 +851,7 @@ func (s *Switch) getLocalLink(pkt *htlcPacket, htlc *lnwire.UpdateAddHTLC) (
// If the link was not found for the outgoingChanID, an outside
Copy link
Contributor

Choose a reason for hiding this comment

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

This logic

lock indexMtx
try to get LinkByShortID
if fails check baseIndex
retry to get LinkBysShortID with the new scid

is similar to the one in GetLinkByShortID I think we could simply call that function here.

@@ -867,7 +867,7 @@ func (s *Switch) getLocalLink(pkt *htlcPacket, htlc *lnwire.UpdateAddHTLC) (
link, err = s.getLinkByShortID(baseScid)
if err != nil {
log.Errorf("Link %v not found", baseScid)
return nil, NewLinkError(&lnwire.FailUnknownNextPeer{})
return nil, NewLinkError(&lnwire.FailTemporaryChannelFailure{})
Copy link
Contributor

Choose a reason for hiding this comment

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

Doesn't this also apply to non zero conf channels? Are we currently sending FailTemporaryChannelFailure instead of FailUnknownNextPeer for those?

@C-Otto C-Otto marked this pull request as draft August 7, 2022 09:41
@C-Otto
Copy link
Contributor Author

C-Otto commented Aug 7, 2022

I don't understand enough of this code and sadly the tests also didn't help much (I'm used to tests with 10 lines max...). I'm closing this PR as I noticed the actual error is determined in another place, and I'm unable to differentiate between "offline" and "unknown".

@C-Otto C-Otto closed this Aug 7, 2022
@C-Otto C-Otto deleted the temporary-channel-failure-for-offline-peer branch March 31, 2023 14:54
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.

Sending incorrect onion error for "peer offline"
2 participants