You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Registry canary failed: fresh npx create-objectstack install is broken #20382
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.
This 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.
Read 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:
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.
⚠ ✓ 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.
Closed duplicate: the same registry-canary failure as #19510. The cause is release lag, and no release has happened since.
Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-09-28T05:53Z. This was checked first as a P0 suspect (first road step). ⛔ It is not one.
What failed. Read from the job log (run 36379740112, job 108792833246) through the Actions logs API, ⛔ not inferred from the title.
Scaffold, npm install and npm run build pass.
The boot passes the job's own test: 「ok — the boot log names no failed plugin, capability or core service」, with 35 plugins including Auth.
The run exits on the first auth probe: GET /auth/get-session (anonymous — must be REFUSED): expected HTTP 401, got 200, body null.
The weekly publish-smoke registry canary failed: a fresh
npx create-objectstack@latestproject no longer completes the first-run path against the npm registry — scaffold, npm install, npm run build, then auth + REST CRUD.This job installs PUBLISHED artifacts, so a fix already merged to
maindoes NOT clear it — only a release does. Check whether the range or template at fault is already fixed onmainbefore opening new work.Read 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:
failed to loadWARN 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.getService(#4835) #4902/[finding] create-objectstack: non-blank remote templates fail firstnpm run buildon published 16.1.0 — fix is at HEAD, needs 17.0.0 release + canary verification #7644/All five published remote templates fail firstnpm run buildon GA create-objectstack@17.0.0 — templates still authorenable.trash/enable.mru, removed in the 16.x line #8677 class; the fix is in create-objectstack or the template it ships.⚠
✓ Server is readyand 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.Run log: https://github.com/objectstack-ai/objectstack/actions/runs/36379740112