jschoubben
e6e1e3bc89
On 2026-10-09 a release's gate on the control node read the machine's
report against a newer send another plan had just made there, failed
three builds the machine had reported healthy, and put them back on
every machine to a controller older than the store's schema; that
controller then passed the newer plan's gate from its own health.
- A gate keeps what its send carried (digest, sequence) and reads the
report against it; a report on the last send is on it too.
- A gate judges only the build the machine was last sent: another build
there supersedes the judging — no verdict, nothing put back.
- A controller is told its build (MESH_CONTROLLER_VERSION, ${version}
in a process's env) and records how far it reads the store's schema;
a put-back to a build that reaches less, or never said, is refused
and the current build kept, said as urgent.
- A release's open gate holds other sends of its modules there, and a
plan's own first send waits on it.
11 lines
690 B
SQL
11 lines
690 B
SQL
-- A controller records, when it serves, how far the store's schema reaches in the build it is (novox/hq
|
|
-- issue 352): the highest migration it carries, by its build's version. A gate that fails the controller's
|
|
-- build puts the build before it back, and on 2026-10-09 that build was older than the migrations the
|
|
-- failed one had applied: it started, said it was behind its own row, and judged the next gate half-blind.
|
|
-- A put-back now reads this and keeps the current build when the one before it reaches less than the store.
|
|
create table controller_schema (
|
|
build text primary key,
|
|
reach integer not null,
|
|
recorded timestamptz not null default now()
|
|
);
|