mirror of
https://github.com/openclaw/openclaw.git
synced 2026-08-21 10:01:37 -06:00
Peter Steinberger
782d52c8b8
Blacksmith's image tracks an older runner-images snapshot. Measured on a leased box 2026-08-16, its toolcache holds Node 20.20.0, 22.22.0 and 24.13.0 while this repo's engines floor is >=22.22.3 and >=24.15.0 -- short by three and two patches. Every candidate is rejected, so all 306 of 306 sampled jobs fell through to a nodejs.org download. GitHub-hosted runners carry 24.19.0 and resolve from the toolcache in about a second, which is why only Blacksmith pays. Normally that download is 2.6s (p99 3.3s), but ~46 jobs fetch the same 50 MB simultaneously and the mirror throttles: three of 53 sampled runs had setup-node medians of 44-93s with maxes to 139s, and because every job pays at once it lands whole on the wall -- those runs went ~210s to 325s. Keep the payload in the Actions cache, which Blacksmith serves from its colocated backend. Measured on Blacksmith: cold 1605ms, warm 77ms. Restores are prefix-keyed and the save carries the resolved patch. An exact key would be worse than nothing: cache entries are immutable and an exact hit suppresses the post-job save, so a floating `24.x` key would pin the first Node it ever saw and, once the floor advanced past it, every job would restore the rejected payload and re-download forever. Keying the save on the installed version lets a newer resolve publish a new entry that later prefix restores pick up. A rejected payload is pruned before the replacement installs, because the entry is saved wholesale and a leftover would ride along in every future save. Windows keeps its existing path. Proven on Blacksmith across cold, warm, stale and truncated-binary cases; both guards are mutation-checked. This stays useful even if Blacksmith refreshes their image: the floor moves independently of the snapshot, so the gap recurs. The image refresh is still the better fix and is worth asking them for.