Skip to content

RouteDigestTracker truncates seqNo to 32 bits when computing the route digest #138

Description

@trancee

Context

Found during final review of #130's implementation. Pre-existing on main (not introduced by #130), but worth tracking now that #130 seeds route seqno from epoch-millis (a genuinely 64-bit-scale value), making the truncation newly relevant.

RouteDigestTracker.encode() writes route.seqNo.toInt() (writeIntLittleEndian) when computing the bytes fed into the route-table digest hash. This silently drops the high 32 bits of a Long seqNo. Two seqno values differing only in their high 32 bits (e.g. epoch-millis values ~49.7 days apart) would collide in the digest.

Impact

Low practical severity: the wire frame itself still carries the full Long seqNo (only the digest computation truncates), and a collision only means a digest-mismatch resync might be skipped when it shouldn't be — not a correctness bug in routing itself, just a very rare missed-resync opportunity.

Ask

Widen RouteDigestTracker.encode() to hash the full 64-bit seqNo (writeLongLittleEndian or equivalent) instead of truncating to 32 bits. Confirm this doesn't require a wire-format change (it shouldn't — RouteDigest carries an opaque digest value, not the seqno itself; only the internal hash-input computation changes, and every node computes it the same way).

Out of scope

Any other change to RouteDigestTracker's digest algorithm.

Metadata

Metadata

Assignees

No one assigned

    Labels

    ready-for-agentFully specified, ready for an AFK agent

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions