Merge pull request 'The catalogue prepares its own schema instead of migrating at start' (#130) from feat/the-catalogue-prepares-its-own-schema into main

modules/mesh-catalog/Dockerfile

@@ -22,7 +22,7 @@ COPY . .
 # The compiler is invoked by its real path rather than through node_modules/.bin, whose entries are
 # symlinks to a launcher that requires its library relatively — resolved away when the base image
 # was assembled.
-RUN node /app/node_modules/typescript/bin/tsc pg.d.ts store.ts index.ts tools/index.ts \
+RUN node /app/node_modules/typescript/bin/tsc pg.d.ts store.ts index.ts tools/index.ts prepare/index.ts \
       --module NodeNext --moduleResolution NodeNext --target ES2022 --outDir dist
 
 # **A module may need something the base image does not carry.** The base holds what every module
@@ -48,3 +48,8 @@ COPY --from=build /deps/node_modules /app/modules/mesh-catalog/node_modules
 # to listen for what the builder announces. Serve binds the broker first, then imports these, so
 # `on()` has something to subscribe to.
 ENV MESH_TOOL_MODULES=/app/modules/mesh-catalog/dist/index.js,/app/modules/mesh-catalog/dist/tools/index.js
+
+# And what prepares this module's state, for the runtime's `prepare` mode (novox/hq ADR 0135). Named
+# here, beside the entrypoints above, because the module knows which of its files prepares its state
+# and nothing else could: the mesh asks one word and this says what answers it.
+ENV MESH_PREPARE=/app/modules/mesh-catalog/dist/prepare/index.js

modules/mesh-catalog/index.ts

@@ -14,10 +14,12 @@ import { Graph, type Made } from "./store.js";
 
 const graph = Graph.fromEnv();
 
-// Before subscribing, and idempotent. The runtime is restarted until its store is reachable, which
-// is the same arrangement model-usage uses: a schema step that had to reach the provider over the
-// overlay would block the very apply that brings the overlay up.
-await graph.migrate();
+// The schema is not brought up here. The mesh prepares this module's state before it starts this
+// version, and does not start it if that failed (novox/hq ADR 0135) — see prepare/index.ts. Doing it
+// at start made a schema that could not be reached a crash loop instead of a stop, with the graph
+// keeping a gap and nothing saying so. The reason it used to be here — that a step blocking the apply
+// would block the very apply that brings the overlay up — stopped being true when a step's failure
+// became this module's business and not the machine's (ADR 0136).
 
 /** What the builder says when it has built something. */
 interface Built {

modules/mesh-catalog/module.json

@@ -37,6 +37,7 @@
     "rebuild-needed",
     "catching-up"
   ],
+  "prepares": true,
   "resources": [
     {
       "id": "mesh-state",

modules/mesh-catalog/prepare/index.ts

@@ -0,0 +1,17 @@
+// 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();

modules/mesh-catalog/tsconfig.json

@@ -12,6 +12,7 @@
     "pg.d.ts",
     "store.ts",
     "index.ts",
-    "tools/index.ts"
+    "tools/index.ts",
+    "prepare/index.ts"
   ]
 }