Skip to content

fix(deps): follow trac-msb to hyperdht 6.29.6 - #37

Merged
TracSystems merged 1 commit into
mainfrom
fix/trac-msb-hyperdht-6.29.6
Sep 16, 2026
Merged

TracSystems merged 1 commit into
mainfrom
fix/trac-msb-hyperdht-6.29.6

Conversation

@TracSystems

Copy link
Copy Markdown
Contributor

Companion to Trac-Systems/main_settlement_bus#802. Re-pins trac-msb to ea72a9c, which moves hyperdht 6.27.0 → 6.29.6.

Why

A long-running peer aborts roughly every few days:

TypeError: Cannot read properties of null (reading 'buffer')
    at crypto_generichash_update (sodium-native/index.js:445)
    at crypto_generichash_batch (sodium-native/index.js:405)
    at annSignable (hyperdht/lib/persistent.js:275)
    at Persistent.onunannounce (hyperdht/lib/persistent.js:62)

hyperdht installs its persistent request handlers on a once('persistent') listener and never tears them down, while dht.id returns null for as long as the node is ephemeral — and an adaptive node returns to ephemeral on every wakeup or network change. In 6.27.0 the dispatcher only checked that the handlers existed, so an inbound UNANNOUNCE reached onunannounce, which passes that null id into sodium.crypto_generichash_batch, where it is dereferenced in C.

Fixed upstream in hyperdht 6.29.4 — holepunchto/hyperdht#242, 8f66a11:

- if (this._persistent === null) return false
+ if (this._persistent === null || this.id === null) return false

Why this pin has to move too, not just the consumer's

This is the part worth catching. trac-peer depends on trac-msb at its own exact sha. A consumer (e.g. intercom) that bumps only its trac-msb pin ends up with a second, nested trac-msb under node_modules/trac-peer/ — still carrying hyperdht 6.27.0. The lockfile then looks fixed while the peer keeps crashing, because the nested copy is what resolves at runtime.

Verified both ways on the lockfile:

before after
node_modules/hyperdht 6.20.5 6.29.6
node_modules/trac-msb/node_modules/hyperdht 6.27.0 removed (deduped)

Net lockfile change is 8 insertions / 39 deletions — the bump plus the removal of that nested subtree. node_modules/pear-runtime/node_modules/hyperdht stays at 6.33.0, unchanged and pre-existing.

Notes

  • 6.29.6 is the last release of the 6.29 line: the guard plus two small fixes, no new dependencies. Deliberately not 6.30.0+, which adds the "closest nodes in key" feature, a new hyperdht-address dependency, and parallel pre-connect on FIND_PEER.
  • Version left at 0.4.9; consumers pin this repo by sha.
  • Merge order: main_settlement_bus#802 first, then this, then the consumer re-pins both.

🤖 Generated with Claude Code

Re-pins trac-msb to Trac-Systems/main_settlement_bus@ea72a9c, which bumps
hyperdht 6.27.0 -> 6.29.6 to pick up the null node-id guard released upstream in
hyperdht 6.29.4 (holepunchto/hyperdht#242).

Without it, a long-running peer aborts roughly every few days: hyperdht keeps
its persistent request handlers installed for the life of the node while
`dht.id` returns null for as long as the node is ephemeral, and an adaptive node
returns to ephemeral on every wakeup or network change. In 6.27.0 the dispatcher
did not check the id, so an inbound UNANNOUNCE reached `onunannounce`, which
passes that null into `sodium.crypto_generichash_batch` and aborts the process.

THIS PIN HAS TO MOVE TOO, not just the consumer's. This package depends on
trac-msb at its own exact sha, so a consumer that bumps only its own trac-msb
pin gets a SECOND, nested trac-msb here — still carrying hyperdht 6.27.0 — and
the peer keeps crashing while the lockfile looks fixed. Verified: with both pins
on ea72a9c the tree dedupes back to one hyperdht, 6.29.6, and the nested
node_modules/trac-msb/node_modules/hyperdht@6.27.0 entry disappears.

The version is left at 0.4.9; consumers pin this repo by sha.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@TracSystems
TracSystems merged commit 54a79ff into main Sep 16, 2026
4 checks passed
TracSystems added a commit to Trac-Systems/intercom that referenced this pull request Sep 16, 2026
Re-pins both framework dependencies:

  trac-msb  7220c257 -> ea72a9c8  (Trac-Systems/main_settlement_bus#802)
  trac-peer 370e81cf -> e4b52ad1  (Trac-Systems/trac-peer#37)

Both carry one change: hyperdht 6.27.0 -> 6.29.6, for the null node-id guard
released upstream in hyperdht 6.29.4 (holepunchto/hyperdht#242).

Without it a long-running peer aborts roughly every few days. hyperdht keeps its
persistent request handlers installed for the life of the node, while `dht.id`
returns null for as long as the node is ephemeral — and an adaptive node returns
to ephemeral on every wakeup or network change. In 6.27.0 the dispatcher checked
only that the handlers existed, so an inbound UNANNOUNCE reached
`Persistent.onunannounce`, which passes that null into
`sodium.crypto_generichash_batch`, where it is dereferenced in C:

    TypeError: Cannot read properties of null (reading 'buffer')
      at annSignable (hyperdht/lib/persistent.js:275)
      at Persistent.onunannounce (hyperdht/lib/persistent.js:62)

BOTH PINS MOVE TOGETHER, and that is the point. trac-peer depends on trac-msb at
its own exact sha, so bumping only this repo's trac-msb pin installs a SECOND,
nested trac-msb under node_modules/trac-peer — still carrying hyperdht 6.27.0.
The lockfile then reads as fixed while the peer keeps crashing on the nested
copy. Measured: bumping trac-msb alone added 12 lockfile entries including
node_modules/trac-peer/node_modules/hyperdht@6.27.0. With both pins moved the
tree stays flat — added 0, removed 0, a single hyperdht at 6.29.6, one trac-msb
and one trac-peer.

tests/startup-source.test.mjs follows the two shas, which is what it is for, and
gains a case that pins hyperdht itself: version 6.29.6, exactly one hyperdht and
exactly one trac-msb in the lockfile. That last part is the regression guard —
it fails on the nested-duplicate tree that a half-finished pin bump produces.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.

1 participant