@forumone/throughline 1.1.0-pr-281-cab5a91 → 1.1.0

package/CHANGELOG.md

@@ -1,10 +1,10 @@
 # @forumone/throughline
 
-## 1.1.0-pr-281-cab5a91
+## 1.1.0
 
 ### Minor Changes
 
-- cab5a91: Every tool the suite serves records a `system.error` when it throws. Editorial (`find_content_needing_attention`, `get_content_calendar`, `list_my_work`, `search_content`), references (`find_references`, `can_delete`), `check_slug` and `list_job_failures` were added to the MCP collector without an audit writer, so a crash in them reached the log and nowhere else. They now record one, under four new `mcp_server` values: `editorial`, `references`, `fields`, `observability`.
+- c897829: Every tool the suite serves records a `system.error` when it throws. Editorial (`find_content_needing_attention`, `get_content_calendar`, `list_my_work`, `search_content`), references (`find_references`, `can_delete`), `check_slug` and `list_job_failures` were added to the MCP collector without an audit writer, so a crash in them reached the log and nowhere else. They now record one, under four new `mcp_server` values: `editorial`, `references`, `fields`, `observability`.
 
   **Upgrading: a migration.** The audit collection's `mcpServer` select gains four options, which on Postgres is four values on `enum_audit_events_mcp_server`. Run `migrate:create` (with `BLOB_READ_WRITE_TOKEN` set if you use the storage plugin) and apply it before deploying; nothing else changes. A plugin registered by hand without `auditPlugin` still works, and only logs a crash.
 
@@ -14,7 +14,16 @@
 
   - **Confirming a decision from an approval email works on Postgres.** The action endpoint wrote the token's approver id as a string into `decidedBy`, a relationship to a users collection whose ids are numbers there, so every emailed decision failed on Confirm. It now writes the id in the users collection's type, as `request_approval` and `respond_to_approval` do since 1.0.1.
   - **A stored request or a recorded decision is reported as one when its event cannot be sent.** `request_approval`, `respond_to_approval` and the email action endpoint wrote first and then threw if `approval/requested`, `approval/decided` or `approval/discussed` failed to send, reporting an action that had landed as failed. The tools now return it with a `warnings` entry, and the endpoint shows the approver their confirmation and logs the warning — the same rule publishing follows. `sendEventSafely` moved to a shared module for it.
-  - @forumone/throughline-design-system@1.1.0-pr-281-cab5a91
+
+- 8212772: `throughline-payload` fails a Payload CLI run that exits 0 without finishing.
+
+  Intermittently the Payload CLI's config `import()` never settles, and node exits
+  by itself with status 0 having printed nothing and done nothing
+  (payloadcms/payload#17757). A `migrate` that does that reports success over an
+  unmigrated database. Every Payload command that completes calls `process.exit`,
+  so the runner now preloads a guard that turns an exit nobody asked for into
+  status 70, with a message saying to run it again.
+  - @forumone/throughline-design-system@1.1.0
 
 ## 1.0.1
 

package/bin/payload-cli.mjs

@@ -29,6 +29,10 @@ PAYLOAD_CLI_TIMEOUT_MS sets the wall clock; 0 disables it. The default is five
 minutes, except for the `migrate` family (`migrate`, `migrate:create`, …),
 which gets none: a large migration is legitimately long, and `migrate:create`
 can stop at an interactive prompt. Layers 1 and 3 apply regardless.
+
+One more failure is the opposite of a hang: the CLI exits 0 having done nothing
+(payloadcms/payload#17757). `payload-exit-guard.mjs` is preloaded into the child
+to make that exit non-zero — see that file.
 */
 import { execFile, spawn } from 'node:child_process'
 import { createRequire } from 'node:module'
@@ -45,6 +49,13 @@ export const DEFAULT_GRACE_MS = 5_000
 /** Exit code for "gave up waiting", as coreutils `timeout` uses. */
 export const TIMEOUT_EXIT_CODE = 124
 
+/** Preloaded into every run, so a CLI that exits 0 without finishing fails. */
+// A URL, not a path: `--import` refuses a Windows drive path.
+export const EXIT_GUARD = new URL('./payload-exit-guard.mjs', import.meta.url).href
+
+/** The node argv for one run of the Payload CLI at `bin`. */
+export const payloadArgv = (bin, args) => ['--import', EXIT_GUARD, bin, ...args]
+
 const delay = (ms) => new Promise((resolve) => setTimeout(resolve, ms))
 const log = (message) => process.stderr.write(`throughline-payload: ${message}\n`)
 
@@ -337,7 +348,7 @@ export async function main({
   if (process.platform === 'win32') {
     // No process groups and no `ps`: run it plainly rather than not at all.
     if (parsed.mode === 'reap') return
-    const child = spawn(process.execPath, [resolvePayloadBin(cwd), ...parsed.args], {
+    const child = spawn(process.execPath, payloadArgv(resolvePayloadBin(cwd), parsed.args), {
       stdio: 'inherit',
       cwd,
     })
@@ -360,7 +371,7 @@ export async function main({
   }
 
   const store = pidFileStore(root)
-  const childArgv = [bin, ...parsed.args]
+  const childArgv = payloadArgv(bin, parsed.args)
   const child = spawn(process.execPath, childArgv, { stdio: 'inherit', detached: true, cwd, env })
 
   let timer

package/bin/payload-exit-guard.mjs

@@ -0,0 +1,36 @@
+/*
+Preloaded into the Payload CLI by `payload-cli.mjs` (`node --import`), to turn
+one silent failure into a loud one.
+
+Every Payload command that finishes calls `process.exit` — `0` once the work is
+done, `1` on an error. Intermittently the config's dynamic `import()` never
+settles instead (payloadcms/payload#17757): nothing is left on the event loop,
+so Node exits by itself, with status 0, having printed nothing and done
+nothing. A `migrate` that does that reports success over an unmigrated
+database; a `generate:*` reports success over a stale file.
+
+So a natural exit with status 0 is not success here: it is this. This module
+records whether `process.exit` was called, and if it was not, replaces the 0
+with NO_COMPLETION_EXIT_CODE. Any other status — a non-zero code, an uncaught
+error, a signal — is left exactly as it was.
+*/
+
+/** EX_SOFTWARE in sysexits.h: an internal error, not a usage or data error. */
+export const NO_COMPLETION_EXIT_CODE = 70
+
+let called = false
+const exit = process.exit.bind(process)
+process.exit = (code) => {
+  called = true
+  return exit(code)
+}
+
+process.on('exit', (code) => {
+  if (called || code !== 0) return
+  process.stderr.write(
+    'throughline-payload: the Payload CLI exited without finishing — it never ' +
+      'called process.exit, so the command did not run (payloadcms/payload#17757). ' +
+      'Run it again.\n',
+  )
+  process.exitCode = NO_COMPLETION_EXIT_CODE
+})

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@forumone/throughline",
-  "version": "1.1.0-pr-281-cab5a91",
+  "version": "1.1.0",
   "description": "Throughline: an editorial platform for Payload CMS. Publishing, approvals, audit, integrations, email and jobs, with every feature reachable over MCP.",
   "type": "module",
   "main": "./dist/index.js",
@@ -162,7 +162,7 @@
   "dependencies": {
     "zod": "^3.23.0",
     "zod-to-json-schema": "^3.25.2",
-    "@forumone/throughline-design-system": "1.1.0-pr-281-cab5a91"
+    "@forumone/throughline-design-system": "1.1.0"
   },
   "devDependencies": {
     "@payloadcms/db-sqlite": "^3.83.0",
@@ -184,9 +184,9 @@
     "resend": "^6.1.4",
     "typescript": "^5.6.0",
     "vitest": "^4.1.10",
+    "@forumone/throughline-reference-ds": "0.3.10",
     "@forumone/throughline-eslint-config": "0.0.1",
-    "@forumone/throughline-tsconfig": "0.0.1",
-    "@forumone/throughline-reference-ds": "0.3.10-pr-281-cab5a91"
+    "@forumone/throughline-tsconfig": "0.0.1"
   },
   "scripts": {
     "build": "tsc -b",