Repository navigation
Only publish added peers after they were persisted - #1150
Closed
ajaysehwal wants to merge 1 commit into
Closed
ajaysehwal wants to merge 1 commit into
ajaysehwal wants to merge 1 commit into
Conversation
|
I've assigned @tnull as a reviewer! |
ajaysehwal
force-pushed
the
fix-peer-store-unpersisted-peers
branch
from
October 11, 2026 16:25
f115e53 to
7efe262
Compare
Camillarhi
reviewed
Oct 15, 2026
`PeerStore::add_peer` inserted the peer into the in-memory map before awaiting the write. If the write failed, a retry for the same peer hit the existing-entry fast path and returned `Ok(())` without writing, so the peer was reported as stored although it would vanish after a restart. Stage the updated snapshot, persist it, and only then publish it to the in-memory map, mirroring `remove_peer`. The in-memory set now only ever contains durable entries, so a retry after a failed write persists again. Adds regression tests for a failed first write followed by a retry (including restoring the peer from the persisted bytes) and for the failed write leaving memory untouched. AI-assisted: this change was prepared with Claude Code.
ajaysehwal
force-pushed
the
fix-peer-store-unpersisted-peers
branch
from
October 16, 2026 02:19
7efe262 to
1dd661b
Compare
Contributor
Author
|
@tnull , could you please review this PR whenever you have some time ? Thanks! |
cryptokvc
added a commit
to cryptokvc/ldk-node
that referenced
this pull request
Nov 10, 2026
src/peer_store.rs now matches main. Making add_peer publish to memory only after a successful write is what lightningdevkit#1150 does, so this PR no longer touches it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
cryptokvc
added a commit
to cryptokvc/ldk-node
that referenced
this pull request
Nov 10, 2026
Brings the test file up to date with main and adapts the test to the current open_channel signature (channel_config argument). The assertion that the peer is not persisted after the failed write is dropped, since that depends on the add_peer change now left to lightningdevkit#1150; the test still checks that no channel is created and that a retry opens exactly one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Collaborator
|
We chose to fix this a bit more fundamentally, superseded by #1234. |
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
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.
Fixes #1142.
PeerStore::add_peerinserted the peer into the in-memory map before awaiting the write. If the write failed, a retry for the same peer hit the existing-entry fast path and returnedOk(())without writing again. The peer was then reported as stored (e.g., in peer listings), although it would vanish after a restart, losing the automatic reconnection information.We now stage the updated snapshot, persist it, and only then publish it to the in-memory map, mirroring what
remove_peeralready does. The in-memory set therefore only ever contains durable entries, so a retry after a failed write persists again.mutation_lock.We also reworded the docs of
list_peersandget_peer: as changes are now only published after they were persisted, they no longer claim that callers may observe changes that are still being persisted.Testing
Added regression tests in
peer_store.rs:add_peer_is_retried_after_persist_failure: the first write fails and the peer isn't visible, the retry persists it, and aPeerStorerestored from the persisted bytes contains the peer.failed_add_peer_keeps_other_peers_and_retry_persists_all: a failed add leaves existing peers intact, and after the retry the restored store contains both the existing and the new peer.add_peer_retry_is_idempotent_after_unacknowledged_commit: if a write reached the store but wasn't acknowledged, the peer isn't published, and the retry succeeds without duplicating it.All three fail on the previous implementation and pass with this change. The full lib test suite passes.
AI disclosure
This change was prepared with the assistance of Claude Code.