Repository navigation
fix(deps): follow trac-msb and trac-peer to hyperdht 6.29.6 - #30
Merged
Merged
Conversation
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>
TracSystems
force-pushed
the
fix/trac-msb-hyperdht-6.29.6
branch
from
September 16, 2026 02:10
b57a0fc to
87ef4d2
Compare
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.
Last link of a three-repo chain. Re-pins both framework dependencies:
trac-msb7220c257ea72a9c8trac-peer370e81cfe4b52ad1Both carry exactly one change: hyperdht
6.27.0→6.29.6.Why
A long-running peer aborts roughly every few days:
hyperdht installs its persistent request handlers on a
once('persistent')listener and never tears them down, whiledht.idreturns 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 inboundUNANNOUNCEreachedonunannounce, which passes that null id intosodium.crypto_generichash_batch, where it is dereferenced in C.onannouncehas always carried its own|| !this.dht.idguard and never crashed — that asymmetry is the tell.Fixed upstream in hyperdht 6.29.4 — holepunchto/hyperdht#242,
8f66a11:Why both pins move together
This is the part that makes the chain three repos instead of two.
trac-peerdepends ontrac-msbat its own exact sha. Bumping only this repo's trac-msb pin adds 12 lockfile entries, includingnode_modules/trac-peer/node_modules/hyperdht@6.27.0— a second, nested trac-msb still carrying the broken version. The lockfile reads as fixed while the peer keeps crashing on the nested copy.Measured on the lockfile:
node_modules/hyperdhtnode_modules/trac-peer/node_modules/hyperdhtAfter this PR the tree holds a single hyperdht (6.29.6), one trac-msb and one trac-peer.
Notes
6.29.6is 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 newhyperdht-addressdependency, and parallel pre-connect onFIND_PEER— behaviour changes that do not belong in a crash fix.versionuntouched, since consumers pin by sha.🤖 Generated with Claude Code