jschoubben
4258f01614
It brought its schema up inside its runtime, on every start. That made a schema it could not reach a crash loop rather than a stop, with the module graph keeping a gap and nothing saying so — which is how a whole morning's builds went unrecorded. The mesh now prepares this module's state before it starts this version and does not start it if that failed (novox/hq ADR 0135): the work moves to an entrypoint the image names in MESH_PREPARE, beside the entrypoints it already names. The reason it was at start — that a step blocking the apply would block the very apply bringing the overlay up — stopped being true when a step's failure became its module's business rather than the machine's (ADR 0136).
18 lines
974 B
TypeScript
18 lines
974 B
TypeScript
// The catalogue's state, brought to the shape this version needs (novox/hq ADR 0135).
|
|
//
|
|
// **The mesh runs this before the version that needs it, and does not start that version if it
|
|
// fails** — and the refusal reaches this module and nothing else on the machine
|
|
// (novox/hq ADR 0136). That is the whole difference from where this used to happen: at start, inside
|
|
// the runtime, a schema that could not be brought up was a crash loop, the graph kept a gap, and
|
|
// nothing anywhere said so.
|
|
//
|
|
// Nothing here connects to the broker. Preparation runs before the version that would use it, so
|
|
// there is nothing yet to talk to; the runtime's `prepare` mode imports this and awaits it, and this
|
|
// process exiting non-zero is how the host knows not to start the runtime.
|
|
import { Graph } from "../store.js";
|
|
|
|
const graph = Graph.fromEnv();
|
|
await graph.migrate();
|
|
console.log("[mesh-catalog] the module graph's schema is what this version needs");
|
|
await graph.close();
|