mirror of
https://github.com/logos-messaging/js-waku.git
synced 2026-06-24 02:09:27 +00:00
070c86c0eb
Tests built on `runNodes` (Store, Filter single-node, etc.) start a single nwaku container and a js-waku LightNode. LightNodes never join the gossipsub mesh, so the nwaku ends up with zero mesh peers on the test topic. After nwaku PR #3669 (Jan 2026) the REST endpoint `POST /relay/v1/auto/messages` now returns HTTP 400 with `NoPeersToPublish` instead of silently succeeding in that state, which causes `ServiceNode.sendMessage()` to return `false` and fails every test that seeds the store via REST publish. That broke ~50/56 of the failing assertions in the nwaku `js-waku-node` CI job and the job has been red on every master run since. Fix the test harness rather than reverting the (correct) nwaku change: - `runNodes` now starts a second relay-only `ServiceNode` chained to the primary via `--staticnode`, subscribed to the same shards/topics. Once the gossipsub mesh GRAFTs, REST publishes on the primary have a real mesh peer and succeed. - The peer's lifecycle is bound to the primary through a new private `companion` field + `setCompanion()` getter; existing `tearDownNodes` calls keep working unchanged. - Add `ServiceNode.waitForMeshPeers(pubsubTopics, {timeoutMs})` polling `/admin/v1/peers/mesh`, called before `runNodes` returns so the first publish doesn't race the heartbeat. Doesn't touch `ServiceNodesFleet` (already multi-node); doesn't address the Filter Multiple-Service-Nodes duplication or Peer Exchange compliance timeouts surfaced in the same run — those are separate bugs.