The delivery view reads only the keys a call names, in parallel, so node_haves and assigner_wants answer within their time (issue 1945) #52

2026-10-25T21:40:58Z

mesh-tools commented

2026-10-25 21:40:58 +00:00

Issue 1945 (note 43): mesh-delivery-view.node_haves and assigner_wants did not answer within 30 s at 21:20, 21:39-21:43 and 22:23-22:28 on 2026-10-25, with or without node/module, which kept the lead from reading whether a delivery landed (the bus node's have, the bridge's acceptance).

Cause: they listed every key of their bucket, read each value one after another (two bus requests per value through the tool runner), and filtered by node and module only after reading.

node and module given: one direct read of that key (the SDK's own WantKey, WantNodeKey, HaveKey); nothing listed.
node or module alone: keys filtered (parsed with the SDK's parsers, exact match) before any value is read.
values read 16 at a time, at most 1000 per call; the answer says cut and how to narrow it when it stops there.
indexer_modules, indexer_candidates and builder_builds read in parallel the same way (builder_builds keeps its limit and 200-read bound).

In its test (1 ms per read): assigner_wants node+module 600 reads/636 ms → 1 read/1 ms; node_haves node+module 1200 reads/1.27 s → 1 read/1 ms; node_haves all → 98 ms, said cut.

Checked: go test -race, go vet -tags integration; try-1792963995122652538 passed. No new top-level tests (rows with a fake bucket that counts reads, failing on the old code). Read-only tools: one review round on the smaller model, weighed against the risk (rules-are-weighed). Note kept: node_haves {node, module: node} now refuses loudly instead of answering empty; HaveNodeKey would give the node's facts.

Reviewed-by: review-view@shanks at 41f25d3129

Issue 1945 (note 43): mesh-delivery-view.node_haves and assigner_wants did not answer within 30 s at 21:20, 21:39-21:43 and 22:23-22:28 on 2026-10-25, with or without node/module, which kept the lead from reading whether a delivery landed (the bus node's have, the bridge's acceptance). Cause: they listed every key of their bucket, read each value one after another (two bus requests per value through the tool runner), and filtered by node and module only after reading. - node and module given: one direct read of that key (the SDK's own WantKey, WantNodeKey, HaveKey); nothing listed. - node or module alone: keys filtered (parsed with the SDK's parsers, exact match) before any value is read. - values read 16 at a time, at most 1000 per call; the answer says `cut` and how to narrow it when it stops there. - indexer_modules, indexer_candidates and builder_builds read in parallel the same way (builder_builds keeps its limit and 200-read bound). In its test (1 ms per read): assigner_wants node+module 600 reads/636 ms → 1 read/1 ms; node_haves node+module 1200 reads/1.27 s → 1 read/1 ms; node_haves all → 98 ms, said cut. Checked: go test -race, go vet -tags integration; try-1792963995122652538 passed. No new top-level tests (rows with a fake bucket that counts reads, failing on the old code). Read-only tools: one review round on the smaller model, weighed against the risk (rules-are-weighed). Note kept: node_haves {node, module: node} now refuses loudly instead of answering empty; HaveNodeKey would give the node's facts. Reviewed-by: review-view@shanks at 41f25d3129fda2a6b36ae90f8afc6c57d7da49f0

mesh-tools added 1 commit 2026-10-25 21:40:58 +00:00

Read only the keys a view tool needs, in parallel, so node_haves and assigner_wants answer within the call's 30 s

mesh/delivery merged: source.main moved to novox/mesh-delivery@ce7d60cb6ed0

Details

mesh/check pass 41f25d3129fd on 73be3df28cd4 | unit 21 run, 579 kept | integration 21 run, 655 kept | composition passed on shanks

41f25d3129

On 2026-10-25 node_haves and assigner_wants timed out at 30 s four times, even narrowed to one node and one module,
while assigner_want answered at once. Each listed every key of its bucket and then read every value one after the
other, filtering only afterwards; every value is a round trip from the tool through the runtime to the bus, which
opens the bucket and gets the key, so a few hundred keys outlasted the call. Now a node and a module read that one
key directly, a node or a module alone filters the keys before any value is read, and the values are read sixteen
at a time, at most 1000 a call, the answer saying when it was cut. indexer_modules, indexer_candidates and
builder_builds read their values the same parallel way. The kind: a read tool that reads a whole bucket key by key;
every list tool of the view is covered.

mesh-tools commented

2026-10-25 21:41:04 +00:00

Delivery novox/mesh-delivery@41f25d3129fd — merged since 2026-10-25T22:03:23Z

Source — source.main moved to novox/mesh-delivery@ce7d60cb6e. Whether it reached the machines is mesh-delivery-view's, derived from source.main, the wants and the haves.

Transitions

2026-10-25 21:41 (new) → proposed (announced): novox/mesh-delivery#52's head announced
2026-10-25 21:42 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail
2026-10-25 22:03 ready → merged (merged): on the trunk its modules follow: merged there

The commit's note under refs/notes/mesh-plan keeps every transition of this change up to its merge: git log --notes=mesh-plan.

**Delivery** `novox/mesh-delivery@41f25d3129fd` — **merged** since 2026-10-25T22:03:23Z **Source** — source.main moved to novox/mesh-delivery@ce7d60cb6ed0. Whether it reached the machines is `mesh-delivery-view`'s, derived from `source.main`, the wants and the haves. **Transitions** - 2026-10-25 21:41 (new) → proposed (announced): novox/mesh-delivery#52's head announced - 2026-10-25 21:42 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail - 2026-10-25 22:03 ready → merged (merged): on the trunk its modules follow: merged there The commit's note under `refs/notes/mesh-plan` keeps every transition of this change up to its merge: `git log --notes=mesh-plan`.

jschoubben merged commit ce7d60cb6e into main

2026-10-25 22:03:21 +00:00

jschoubben deleted branch fix/view-reads-fast

2026-10-25 22:03:22 +00:00

mesh-tools referenced this pull request

2026-10-25 23:43:35 +00:00

Builder and checker read tools read only what they answer, in parallel and bounded (issue 1827) #55

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-delivery#52