routing: allow misson control manager to startup despite errors #10383
Conversation
This file contains hidden or 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
2 tasks
ziggie1984
force-pushed
the
bugfix/fix-mission-control-startup
branch
from
56f5ad6 to
967ee2a
Compare
ziggie1984
force-pushed
the
bugfix/fix-mission-control-startup
branch
from
961c474 to
798ae45
Compare
2 tasks
ziggie1984
force-pushed
the
bugfix/fix-mission-control-startup
branch
from
798ae45 to
4749b60
Compare
bitromortac
approved these changes
Dec 2, 2025
Collaborator
bitromortac
left a comment
bitromortac
left a comment
There was a problem hiding this comment.
LGTM, it fixes the problem ⚡. It would be nice to remove that code again in the future if we can be sure we're in a clean state (and only allow future sane writes) for example using a possible migration to sql. Perhaps it would be good to add a TODO/issue for a future migration?
| addresses](https://github.com/lightningnetwork/lnd/pull/10341) were added to | ||
| the node announcement and `getinfo` output. | ||
|
|
||
| * [Fix a startup issue in LND when ecounntering a |
ziggie1984
force-pushed
the
bugfix/fix-mission-control-startup
branch
from
4749b60 to
ca9ba1c
Compare
We now allow the mission control manager to skip over deserializable errors. We cannot repair this these results but we just skip over it so we can startup properly. When fetchAll() encounters entries that fail to deserialize, in addition to skipping them, now also: - Delete the corrupted entries from the database - Remove them from the in-memory keysMap and keys tracking structures This prevents corrupted entries from: - Being counted toward maxRecords, which would cause valid entries to be pruned prematurely - Persisting in the database indefinitely - Causing inaccurate entry counts in startup logs
ziggie1984
force-pushed
the
bugfix/fix-mission-control-startup
branch
from
ca9ba1c to
17b77b6
Compare
Collaborator
Author
|
added a TODO |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
We now allow the mission control manager to skip over deserializable
errors. We cannot repair this these results but we just skip over
it so we can startup properly. Moreover we also delete those corrupted values.
So we still don't know why it happens so rarely now this problem is fixed anyways because we now validate the ExtraTLVData when receiving a payment error:
Invalid data gets rejected naturally: If a peer sends a ChannelUpdate with malformed ExtraOpaqueData:
- DecodeFailure() fails
- htlcswitch returns UnknownForwardingError (without the ChannelUpdate)
- Mission control stores the failure but without the corrupted ChannelUpdate data
So we basically only have to deal with old data here.