anbaric-cloud-hosting 1.24.0 → 1.25.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "anbaric-cloud-hosting",
-  "version": "1.24.0",
+  "version": "1.25.0",
   "description": "Anbaric Cloud hosting service: Postgres-backed job persistence and queuing exposed over an HTTP API",
   "license": "MIT",
   "author": "chris@anbaric.ai",
@@ -18,18 +18,18 @@
     "@aws-sdk/client-s3": "^3.1110.0",
     "@aws-sdk/client-secrets-manager": "^3.700.0",
     "@aws-sdk/client-servicediscovery": "^3.1110.0",
-    "anbaric-data-store": "^1.24.0",
-    "anbaric-plugins": "^1.24.0",
-    "anbaric-tsapi": "^1.24.0",
-    "anbaric-web": "^1.24.0",
+    "anbaric-data-store": "^1.25.0",
+    "anbaric-plugins": "^1.25.0",
+    "anbaric-tsapi": "^1.25.0",
+    "anbaric-web": "^1.25.0",
     "esbuild": "^0.28.2",
     "pg": "^8.16.0"
   },
   "devDependencies": {
     "@types/node": "^26.2.0",
     "@types/pg": "^8.15.0",
-    "anbaric-impl-cloud": "^1.24.0",
-    "anbaric-state-machine": "^1.24.0",
+    "anbaric-impl-cloud": "^1.25.0",
+    "anbaric-state-machine": "^1.25.0",
     "tsx": "^4.20.0",
     "typescript": "^7.0.2"
   },

package/src/app-admin/launch.ts

@@ -9,6 +9,15 @@ import {AdminServer} from "./AdminServer";
    and its admin port stops answering `ping`. */
 const TSX = process.env.ANBARIC_TSX_BIN ?? "/anbaric/node_modules/.bin/tsx";
 
+/* A host can name a module to load before the app's own entry point, which is
+   how it registers implementations an app picks up through the factories -
+   anything the app should be able to use without knowing it is there. It runs
+   in the app's process, so registering from the launcher would be too early. */
+const preloadArgs = () => {
+    const preload = process.env.ANBARIC_APP_PRELOAD;
+    return preload ? ["--import", preload] : [];
+};
+
 const main = async () => {
     const entryPoint = process.argv[2];
     if (!entryPoint) throw new Error("Expected the app entry point as the first argument");
@@ -17,7 +26,7 @@ const main = async () => {
     const port = await admin.listen();
     console.log(`[anbaric-admin] listening on ${port}`);
 
-    const app = spawn(TSX, [entryPoint], { stdio: "inherit" });
+    const app = spawn(TSX, [...preloadArgs(), entryPoint], { stdio: "inherit" });
 
     const shutdown = (signal : NodeJS.Signals) => app.kill(signal);
     process.on("SIGTERM", shutdown);

package/src/data-store/PostgresJobPersistence.ts

@@ -49,9 +49,13 @@ class PostgresJobPersistence extends JobPersistence {
             await client.query(
                 `INSERT INTO jobs (id, state, properties, workflow_id, app_id, started_at, started_by, last_updated, killed, status, waiting_for)
                  VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11)
+                 -- killed is deliberately not updated here. Only kill() sets it,
+                 -- and a save carries whatever the job looked like when it was
+                 -- read: a pass that began before a kill would otherwise write
+                 -- killed=false straight back and bring the job back to life.
                  ON CONFLICT (id) DO UPDATE SET state = EXCLUDED.state, properties = EXCLUDED.properties,
                      workflow_id = EXCLUDED.workflow_id, app_id = EXCLUDED.app_id, last_updated = EXCLUDED.last_updated,
-                     killed = EXCLUDED.killed, status = EXCLUDED.status, waiting_for = EXCLUDED.waiting_for`,
+                     status = EXCLUDED.status, waiting_for = EXCLUDED.waiting_for`,
                 [job.id, job.state, Object.fromEntries(job.properties), job.workflowId, job.appId || null,
                     job.startedAt, job.startedBy, job.lastUpdated, job.killed, job.status, job.waitingFor ?? null],
             );