34 lines
1.3 KiB
Markdown
34 lines
1.3 KiB
Markdown
---
|
|
status: open
|
|
opened: 2026-10-04
|
|
located-in: []
|
|
fixed-by:
|
|
amended-design:
|
|
---
|
|
|
|
# 221 — A build machine learns a new builder only from a push
|
|
|
|
## What was observed
|
|
|
|
2026-10-04. A controller merge changed how TypeScript bundles are built: one file per entrypoint
|
|
instead of a package directory. Its plan finished, and six bundles were rebuilt right after. They
|
|
came out in the old shape, because the build machines still ran the previous builder. They got the
|
|
new one only from the next push. Rebuilt after that push, the same six came out right.
|
|
|
|
The same order showed in the bus grants the same night. A push sent while the controller was still
|
|
the previous build composed grants with the previous code. A second push was needed after the new
|
|
controller had started.
|
|
|
|
## Why it matters beyond this instance
|
|
|
|
A merge to the controller is not in effect when its plan says done. Anything built or pushed in the
|
|
gap uses the old code and looks current. Today only the operator knows to push first and build
|
|
second, and even the operator forgot.
|
|
|
|
## Where to look
|
|
|
|
Whether a controller plan should end by delivering itself to the build machines and the control
|
|
machine, or whether a build should refuse a builder older than the controller that asked for it.
|
|
**How it is checked:** after a controller merge, a build asked right after its plan finishes runs
|
|
the new builder.
|