Skip to content
edgesync Tags and Properties
Login

Tags and Properties

Tags and Properties for Check-in a96fe486ab

Context
2026-05-17
18:47
fix(hub): address pulls to publishing peer to resolve .sync race (#162) (#181)

Three+ hubs sharing a project-code all subscribed to the same broadcast `<prefix>..sync` subject. A `.commit` notification on any one of them caused every other peer to fan out a nats.Request on .sync; every subscribed peer answered, but nats.Request only delivers the first reply. If a stale peer won that race the pull converged against zero blobs and the receiver silently stayed behind.

Two changes close the gap:

1. Each hub now also subscribes to a per-peer addressed sync subject `<prefix>..sync.<peer-id>` (peer-id = the hub's NATS server name). The commit notification carries the publishing hub's peer-id; receivers route their pull-back at that addressed subject so exactly that hub responds. No race regardless of how many other hubs share the project-code.
2. The broadcast `.sync` subscription becomes a NATS queue group (`sync-<project-code>`) so external leaf-agent pushes — which still target the broadcast subject — get exactly one responder per request instead of a fan-out race. Project-code in the queue name scopes the group so unrelated projects sharing a NATS server can't cross-pollinate.

The receiver also drops self-notifications (a publish from this hub round-tripping back via an upstream leaf, which NoEcho doesn't catch across leaf links) and notifications missing a peer-id (older publisher that pre-dates this fix — refusing rather than falling back to a broadcast pull keeps #162 from regressing silently).

`TestCrossLeaf_ThreeHubs_CommitAnnouncePropagatesToAll` is now ungated: it ran red under both -short and full modes before this fix, and passes under both modes (and 10x stability check) after.

Closes #162 Closes #179

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> check-in: a96fe486ab user: [email protected] tags: trunk, main

17:44
test(hub): add 3-hub cross-leaf propagation test (#180)

Mirrors the 2-node TestCrossLeaf_SharedProjectCode_PropagatesCommit shape but with a third leaf attached to the same topology root. Asserts that a commit on any peer propagates to BOTH of the other two peers, both directions.

Reproduces the cross-leaf propagation gap reported in #179 and confirms its underlying cause is the multi-responder .sync race filed as #162: with 3+ hubs subscribing to the same .sync subject every peer answers nats.Request, only the first reply wins, and a stale responder silently starves the pull. The first hop (B -> A) is already enough to surface this — A's .sync request can race against C's empty responder even though A and B are the only nodes that need to talk for that direction.

Gated under -short with a skip pointing to #162 so pre-commit and CI stay green. Without -short the test fails at the 10s wait in ~10s, demonstrating the bug. Remove the skip once #162 is fixed; the test then doubles as the regression sentinel for the 3+ hub topology that production sesh relies on.

No production code changes.

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> check-in: 5c36d5498d user: [email protected] tags: trunk, main

2026-04-26
15:20
Merge pull request #78 from danmestas/add-docs-site

docs: Hugo+hextra docs site with Cloudflare Workers deploy check-in: d59e2dece9 user: [email protected] tags: trunk, v0.0.2