Skip to content

Fix u16 truncation of the persisted event queue and peer store - #1215

Closed
parthod0x wants to merge 1 commit into
lightningdevkit:mainfrom
parthod0x:fix/event-queue-u16-truncation-1138
Closed

parthod0x wants to merge 1 commit into
lightningdevkit:mainfrom
parthod0x:fix/event-queue-u16-truncation-1138

Conversation

@parthod0x

@parthod0x parthod0x commented Oct 28, 2026 •

Copy link
Copy Markdown

Fixes #1138 — completely, at both truncation sites.

EventQueueSerWrapper::write (src/event.rs) and PeerStoreSerWrapper::write (src/peer_store.rs:151) both write their collection length as a plain u16 over an unbounded collection (VecDeque<Event> / the peer HashMap). Above 65,535 entries the count wraps: a 65,536-event queue serializes to length 0, silently dropping every event on the next restart.

This switches both wrappers to lightning::util::ser::CollectionLength — a bare u16 below 65,535 (byte-identical to the current wire format, so existing persisted state still decodes) and 0xffff + u64 above. No migration needed, and no truncation at any size.

Why both sites

#1145 applies the same CollectionLength fix to src/event.rs only. This PR fixes event.rs and the identical defect at peer_store.rs:151, so #1138 is resolved in one change rather than leaving the sibling bug behind. Happy to coordinate with #1145 — e.g. if the event-queue change lands there first, I'll rebase this down to just the peer_store delta — whatever keeps it cleanest for you.

Tests

  • event_queue_round_trips_across_u16_boundary — 65,534 / 65,535 / 65,536 / 65,540 events; fails before (65,536 → length 0), passes after.
  • event_queue_decodes_legacy_u16_length_prefix — the new reader decodes the pre-existing bare-u16 prefix, and the writer still emits a 2-byte prefix for small queues (backward-compatible).
  • 16 event/peer_store tests pass; cargo fmt --all clean; no regressions. (A >65,535-entry peer_store test is impractical — it would need that many distinct on-curve secp pubkeys — but the peer_store path uses the exact CollectionLength idiom the event-queue boundary tests exercise.)

…devkit#1138)

`EventQueueSerWrapper` and `PeerStoreSerWrapper` wrote their collection
length with `(len as u16)` over unbounded collections. Once a queue held
more than 65535 entries the persisted count wrapped (65_536 events wrote
a count of 0), so on restart the reader restored a truncated queue and
application event notifications were silently lost.

Use `lightning::util::ser::CollectionLength` for the length prefix in
both the serialization and deserialization wrappers, matching how LDK
encodes its own collections. This preserves the existing two-byte
encoding for counts below 65535 and extends to larger counts.

Add round-trip tests at 65534/65535/65536/65540 entries and a legacy
two-byte length-prefix decode test to lock in backward compatibility.
@ldk-reviews-bot

ldk-reviews-bot commented Oct 28, 2026 •

Copy link
Copy Markdown

I've assigned @tnull 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.

@ldk-reviews-bot
ldk-reviews-bot requested a review from tnull October 28, 2026 20:10
@tnull

tnull commented Oct 29, 2026

Copy link
Copy Markdown
Collaborator

No, we already have a PR up for this. The issue is borderline wontfix anyways, so we def. don't need two competing PRs for this. Please next time first ask if an issue is up for the taking.

Closing as duplicate.

@tnull tnull closed this Oct 29, 2026
@parthod0x

Copy link
Copy Markdown
Author

Fair enough — #1145 was up well before mine and covers the same fix. I should have checked for an existing PR first; will do next time. Thanks for the pointer, and sorry for the noise.

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.

Avoid truncating persisted event queues above u16::MAX

3 participants