From b0078eae4048805291ffed5cd55e5f7b5e7ce0b8 Mon Sep 17 00:00:00 2001 From: claude Date: Tue, 8 Sep 2026 04:20:33 +0000 Subject: [PATCH 1/3] fix(ci): the registry canary names the plugin-failed-to-load class, and says a fix on main does not clear it MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The canary's triage template offered a closed binary — build failed, or a probe failed — and the failure it actually reported fit neither: AuthPlugin never loaded at boot because @better-auth/core@1.7.3 deleted the export plugin-auth statically imports, and the probe failures were a consequence. The template therefore routed the reader to the probes, away from the range. Add the boot-log branch, order it first (a failed probe is usually a consequence), and name the local reproducer. Also state the property that misled this round's triage: this job installs PUBLISHED artifacts, so a fix merged to main does not clear it — only a release does. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_015QE8qk46e5CHJxyQEUjbf8 --- .github/workflows/publish-smoke.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/publish-smoke.yml b/.github/workflows/publish-smoke.yml index 725c34a8ad..4d9cd2ca9a 100644 --- a/.github/workflows/publish-smoke.yml +++ b/.github/workflows/publish-smoke.yml @@ -279,7 +279,7 @@ jobs: title="Registry canary failed: fresh npx create-objectstack install is broken" existing=$(gh issue list --repo "$GITHUB_REPOSITORY" --state open \ --search "\"$title\" in:title" --json number -q '.[0].number // empty') - body=$(printf 'The weekly publish-smoke registry canary failed: a fresh `npx create-objectstack@latest` project no longer completes the first-run path against the npm registry — scaffold, npm install, npm run build, then auth + REST CRUD.\n\nRead the run log to see WHICH step failed, because the two have different owners:\n\n- **npm run build failed** — the published scaffold is broken on its own second command. This is the #4902/#7644/#8677 class; the fix is in create-objectstack or the template it ships.\n- **an auth or CRUD probe failed** — this is the #3091 class hitting ALREADY-published versions (e.g. a transitive dependency released into a ^ range).\n\nRun log: %s\n' "$run_url") + body=$(printf 'The weekly publish-smoke registry canary failed: a fresh `npx create-objectstack@latest` project no longer completes the first-run path against the npm registry — scaffold, npm install, npm run build, then auth + REST CRUD.\n\nThis job installs PUBLISHED artifacts, so a fix already merged to `main` does NOT clear it — only a release does. Check whether the range or template at fault is already fixed on `main` before opening new work.\n\nRead the run log to see WHICH step failed, because these classes have different owners. **Read the boot log before the probes** — a failed probe is usually a consequence, not the defect:\n\n- **a `failed to load` WARN in the boot log** — a dependency-range problem, and the FIRST thing to check whenever an auth or CRUD probe fails. Specimen: `⚠ AuthPlugin failed to load: The requested module @better-auth/core/db does not provide an export named createLocalAccountIssuer`. A static ESM named import of a missing export is a link-time SyntaxError, so the plugin never loads AT ALL and every later symptom follows from that one failure — core service missing, `sys_*` tables never created, sharing rules never seeded, and the probe failure this job finally exits on. Go to the DECLARED dependency range, NOT to the probe, and establish whether the vendor REMOVED or RENAMED the symbol: the two have different fixes. Reproduce it locally with `pnpm check:vendor-export-contract-resolve`, which installs every version each declared range admits and checks its export surface against what we import.\n- **npm run build failed** — the published scaffold is broken on its own second command. This is the #4902/#7644/#8677 class; the fix is in create-objectstack or the template it ships.\n- **an auth or CRUD probe failed over a CLEAN boot log** — this is the #3091 class hitting ALREADY-published versions (e.g. a transitive dependency released into a ^ range).\n\n⚠ `✓ Server is ready` and the plugin count print on a DEGRADED boot too (#16630), so neither is evidence that the boot was healthy and neither narrows the branches above.\n\nRun log: %s\n' "$run_url") if [ -n "$existing" ]; then gh issue comment "$existing" --repo "$GITHUB_REPOSITORY" \ --body "Still failing as of $run_url" From a7d883063738532a4c1261a2a336825b02b66b78 Mon Sep 17 00:00:00 2001 From: claude Date: Tue, 8 Sep 2026 04:37:27 +0000 Subject: [PATCH 2/3] fix(ci): name the reproducer as its node script, not a pnpm run MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit check:pnpm-acquisition reads a bare `pnpm ` token anywhere in a `run:` body as an invocation, so naming the reproducer that way put registry-canary — a job that acquires no pnpm and needs none — into the population of jobs that run pnpm (census 31, one failing). The underlying script needs no package manager and is what a reader can paste, so name it directly. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_015QE8qk46e5CHJxyQEUjbf8 --- .github/workflows/publish-smoke.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/publish-smoke.yml b/.github/workflows/publish-smoke.yml index 4d9cd2ca9a..d5a962950d 100644 --- a/.github/workflows/publish-smoke.yml +++ b/.github/workflows/publish-smoke.yml @@ -279,7 +279,7 @@ jobs: title="Registry canary failed: fresh npx create-objectstack install is broken" existing=$(gh issue list --repo "$GITHUB_REPOSITORY" --state open \ --search "\"$title\" in:title" --json number -q '.[0].number // empty') - body=$(printf 'The weekly publish-smoke registry canary failed: a fresh `npx create-objectstack@latest` project no longer completes the first-run path against the npm registry — scaffold, npm install, npm run build, then auth + REST CRUD.\n\nThis job installs PUBLISHED artifacts, so a fix already merged to `main` does NOT clear it — only a release does. Check whether the range or template at fault is already fixed on `main` before opening new work.\n\nRead the run log to see WHICH step failed, because these classes have different owners. **Read the boot log before the probes** — a failed probe is usually a consequence, not the defect:\n\n- **a `failed to load` WARN in the boot log** — a dependency-range problem, and the FIRST thing to check whenever an auth or CRUD probe fails. Specimen: `⚠ AuthPlugin failed to load: The requested module @better-auth/core/db does not provide an export named createLocalAccountIssuer`. A static ESM named import of a missing export is a link-time SyntaxError, so the plugin never loads AT ALL and every later symptom follows from that one failure — core service missing, `sys_*` tables never created, sharing rules never seeded, and the probe failure this job finally exits on. Go to the DECLARED dependency range, NOT to the probe, and establish whether the vendor REMOVED or RENAMED the symbol: the two have different fixes. Reproduce it locally with `pnpm check:vendor-export-contract-resolve`, which installs every version each declared range admits and checks its export surface against what we import.\n- **npm run build failed** — the published scaffold is broken on its own second command. This is the #4902/#7644/#8677 class; the fix is in create-objectstack or the template it ships.\n- **an auth or CRUD probe failed over a CLEAN boot log** — this is the #3091 class hitting ALREADY-published versions (e.g. a transitive dependency released into a ^ range).\n\n⚠ `✓ Server is ready` and the plugin count print on a DEGRADED boot too (#16630), so neither is evidence that the boot was healthy and neither narrows the branches above.\n\nRun log: %s\n' "$run_url") + body=$(printf 'The weekly publish-smoke registry canary failed: a fresh `npx create-objectstack@latest` project no longer completes the first-run path against the npm registry — scaffold, npm install, npm run build, then auth + REST CRUD.\n\nThis job installs PUBLISHED artifacts, so a fix already merged to `main` does NOT clear it — only a release does. Check whether the range or template at fault is already fixed on `main` before opening new work.\n\nRead the run log to see WHICH step failed, because these classes have different owners. **Read the boot log before the probes** — a failed probe is usually a consequence, not the defect:\n\n- **a `failed to load` WARN in the boot log** — a dependency-range problem, and the FIRST thing to check whenever an auth or CRUD probe fails. Specimen: `⚠ AuthPlugin failed to load: The requested module @better-auth/core/db does not provide an export named createLocalAccountIssuer`. A static ESM named import of a missing export is a link-time SyntaxError, so the plugin never loads AT ALL and every later symptom follows from that one failure — core service missing, `sys_*` tables never created, sharing rules never seeded, and the probe failure this job finally exits on. Go to the DECLARED dependency range, NOT to the probe, and establish whether the vendor REMOVED or RENAMED the symbol: the two have different fixes. Reproduce it locally with `node scripts/check-vendor-export-contract.mjs --resolve`, which installs every version each declared range admits and checks its export surface against what we import.\n- **npm run build failed** — the published scaffold is broken on its own second command. This is the #4902/#7644/#8677 class; the fix is in create-objectstack or the template it ships.\n- **an auth or CRUD probe failed over a CLEAN boot log** — this is the #3091 class hitting ALREADY-published versions (e.g. a transitive dependency released into a ^ range).\n\n⚠ `✓ Server is ready` and the plugin count print on a DEGRADED boot too (#16630), so neither is evidence that the boot was healthy and neither narrows the branches above.\n\nRun log: %s\n' "$run_url") if [ -n "$existing" ]; then gh issue comment "$existing" --repo "$GITHUB_REPOSITORY" \ --body "Still failing as of $run_url" From 4ec34a519b7a67164ee2ad0f3c45998b606b8229 Mon Sep 17 00:00:00 2001 From: claude Date: Tue, 8 Sep 2026 05:18:29 +0000 Subject: [PATCH 3/3] fix(ci): state the reproducer as prose, not a command the gate tooling can discover MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Naming the reproducer as `node scripts/check-vendor-export-contract.mjs --resolve` traded one false positive for another: dispatch-gates discovers gate families from command-shaped text in `run:` bodies, so the prose became a discovered family inside registry-canary — a job in a workflow that declares no PR-time event. check:pm-dispatch-gates went red on its scheduled-only invariant (4 of 1552 cases), correctly. Any command-shaped text in a workflow `run:` body is read as a real invocation by at least two gates, so point at the workflow that runs the check instead of spelling a command inside guidance prose. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_015QE8qk46e5CHJxyQEUjbf8 --- .github/workflows/publish-smoke.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/publish-smoke.yml b/.github/workflows/publish-smoke.yml index d5a962950d..a2132fee23 100644 --- a/.github/workflows/publish-smoke.yml +++ b/.github/workflows/publish-smoke.yml @@ -279,7 +279,7 @@ jobs: title="Registry canary failed: fresh npx create-objectstack install is broken" existing=$(gh issue list --repo "$GITHUB_REPOSITORY" --state open \ --search "\"$title\" in:title" --json number -q '.[0].number // empty') - body=$(printf 'The weekly publish-smoke registry canary failed: a fresh `npx create-objectstack@latest` project no longer completes the first-run path against the npm registry — scaffold, npm install, npm run build, then auth + REST CRUD.\n\nThis job installs PUBLISHED artifacts, so a fix already merged to `main` does NOT clear it — only a release does. Check whether the range or template at fault is already fixed on `main` before opening new work.\n\nRead the run log to see WHICH step failed, because these classes have different owners. **Read the boot log before the probes** — a failed probe is usually a consequence, not the defect:\n\n- **a `failed to load` WARN in the boot log** — a dependency-range problem, and the FIRST thing to check whenever an auth or CRUD probe fails. Specimen: `⚠ AuthPlugin failed to load: The requested module @better-auth/core/db does not provide an export named createLocalAccountIssuer`. A static ESM named import of a missing export is a link-time SyntaxError, so the plugin never loads AT ALL and every later symptom follows from that one failure — core service missing, `sys_*` tables never created, sharing rules never seeded, and the probe failure this job finally exits on. Go to the DECLARED dependency range, NOT to the probe, and establish whether the vendor REMOVED or RENAMED the symbol: the two have different fixes. Reproduce it locally with `node scripts/check-vendor-export-contract.mjs --resolve`, which installs every version each declared range admits and checks its export surface against what we import.\n- **npm run build failed** — the published scaffold is broken on its own second command. This is the #4902/#7644/#8677 class; the fix is in create-objectstack or the template it ships.\n- **an auth or CRUD probe failed over a CLEAN boot log** — this is the #3091 class hitting ALREADY-published versions (e.g. a transitive dependency released into a ^ range).\n\n⚠ `✓ Server is ready` and the plugin count print on a DEGRADED boot too (#16630), so neither is evidence that the boot was healthy and neither narrows the branches above.\n\nRun log: %s\n' "$run_url") + body=$(printf 'The weekly publish-smoke registry canary failed: a fresh `npx create-objectstack@latest` project no longer completes the first-run path against the npm registry — scaffold, npm install, npm run build, then auth + REST CRUD.\n\nThis job installs PUBLISHED artifacts, so a fix already merged to `main` does NOT clear it — only a release does. Check whether the range or template at fault is already fixed on `main` before opening new work.\n\nRead the run log to see WHICH step failed, because these classes have different owners. **Read the boot log before the probes** — a failed probe is usually a consequence, not the defect:\n\n- **a `failed to load` WARN in the boot log** — a dependency-range problem, and the FIRST thing to check whenever an auth or CRUD probe fails. Specimen: `⚠ AuthPlugin failed to load: The requested module @better-auth/core/db does not provide an export named createLocalAccountIssuer`. A static ESM named import of a missing export is a link-time SyntaxError, so the plugin never loads AT ALL and every later symptom follows from that one failure — core service missing, `sys_*` tables never created, sharing rules never seeded, and the probe failure this job finally exits on. Go to the DECLARED dependency range, NOT to the probe, and establish whether the vendor REMOVED or RENAMED the symbol: the two have different fixes. Reproduce it without waiting for a release using the vendor export-contract check in its resolve mode, which the daily Validate Dependencies workflow already runs: it installs every version each declared range admits and checks that export surface against the symbols we import.\n- **npm run build failed** — the published scaffold is broken on its own second command. This is the #4902/#7644/#8677 class; the fix is in create-objectstack or the template it ships.\n- **an auth or CRUD probe failed over a CLEAN boot log** — this is the #3091 class hitting ALREADY-published versions (e.g. a transitive dependency released into a ^ range).\n\n⚠ `✓ Server is ready` and the plugin count print on a DEGRADED boot too (#16630), so neither is evidence that the boot was healthy and neither narrows the branches above.\n\nRun log: %s\n' "$run_url") if [ -n "$existing" ]; then gh issue comment "$existing" --repo "$GITHUB_REPOSITORY" \ --body "Still failing as of $run_url"