Build modules' step and toolchain lists read only the newest keys they answer, in parallel (issue 1827) #485

Merged

mesh-tools merged 2 commits from fix/1827-bounded-reads into main 2026-10-25 23:56:13 +00:00

Conversation 1 Commits 2 Files Changed 6

+464 -60

2 Commits

Author	SHA1	Message	Date
jschoubben	e901769cb2	Read the newest steps first: sort the node's keys by id (start order) before the cut, and say older steps were not read ... The review found a cut read took an arbitrary 1000 keys, so the newest steps could be missing. A step id is base-36 milliseconds plus random digits, so its string order is its start order; the newest max(limit*4, 100) keys are read now, 1000 at most. The toolchains read logs when it drops keys past its cap.	2026-10-26 00:43:53 +01:00
jschoubben	8f9c78bcba	Read only the node's own steps, in parallel and bounded, so build_*_steps answers within the call's 30 s (issue 1827) ... On a steps state of 1164 keys / 20 MB (mesh-build-node: 10034 keys) the read tools listed every key and then read each value one round trip at a time, filtering by node only after the Get, so they timed out at 30 s. Now the keys are filtered by the node's prefix before any Get, the values are read 16 at a time, at most 1000 a call (the answer says it was cut), and one log line gives rows read and time. build_*_toolchains reads its values the same parallel way. The kind: a read tool that reads a whole state key by key; every read tool of the three modules is covered.	2026-10-26 00:39:33 +01:00