⚠️ publish-smoke: a fresh install of the release candidate answers 401 to an anonymous GET /auth/get-session — red on main since 00:30Z, and it flipped on an identical sha #17960

⚠️ Packed-tarball smoke (release candidate) has been failing on main for ~7.5 hours. An advisory gate red on main is shared damage, so this is filed the moment it was measured rather than held for a sweep.

Filed by the domain:spec execution seat, session session_01MkQhmuuJAVDjmeWNixwDDH, readings taken 2026-09-13T08:20–08:24Z. ⛔ No domain:* or priority:* applied — routing and grading are triage's. ⛔ This seat did not investigate the cause beyond the reading below.

The reading that makes this worth a card: it flipped on an identical sha

GET /repos/objectstack-ai/objectstack/actions/workflows/publish-smoke.yml/runs, newest 30:

Same commit, 36 minutes apart, opposite results. ⇒ the cause is not in the tree. Something outside the repository moved between 23:54Z and 00:30Z. Census of the 30 returned runs: 12 success, 11 failure, 6 cancelled, 1 in progress — the last success is the 23:54Z one, so the failures are a continuous streak, not a scatter.

The symptom, verbatim from the failing step

Run 34746553018, job 103695440454, step 11 Publish smoke (packed tarballs):

== Auth probes (the #3091 failure surface)
── response body ──
{"success":false,"error":{"code":"UNAUTHENTICATED","message":"Sign in first"}}
##[error]GET /auth/get-session (anonymous): expected HTTP 200, got 401

Everything before it passes: 58/70 pinned packages resolved from tarballs with 0 registry leaks, scaffold identity ok, objectstack build ok (dist/objectstack.json, 2155 bytes), dev server healthy on probe #4, and "the boot log names no failed plugin, capability or core service". So this is not a packaging or boot regression — a fresh install of the release candidate boots fine and then answers 401 where the smoke expects 200.

Why the anonymous probe expects 200

GET /auth/get-session is better-auth's session endpoint; the convention it is written against is 200 with a null/empty session for an anonymous caller, which is what lets a client ask "am I signed in?" without handling an error. Something is now answering 401 UNAUTHENTICATED "Sign in first" to that same anonymous call.

The most likely place to look first (⛔ a hypothesis, not a reading)

The smoke installs the RC as packed tarballs but resolves the rest from the registry — 12 of the 70 packages are not pinned. The run log enumerates a better-auth family at better-auth@1.7.3 with @better-auth/utils resolved at two versions in the same tree (0.4.2 and 0.5.0). A registry-side move in that family between 23:54Z and 00:30Z would produce exactly this shape: identical sha, identical repo, different dependency graph, different auth behaviour.

⛔ NOT MEASURED by this seat: what better-auth and its transitive deps resolved to in the 23:54Z run (the passing run's log was not read and its resolution table not diffed against the failing one). That diff is the first thing the card's owner should take, and it either confirms or kills the hypothesis in one reading. ⛔ Also not measured: whether this status is a required check or purely advisory, and whether the same 401 reproduces against a locally built RC.

Blast radius

This gate exists to answer one question — "does a fresh install of the release candidate work for a customer?" — and it has been answering no since 00:30Z. Whatever else is true, no release should be cut while this is red, and every main commit since 00:30Z carries a red publish-smoke / packed-tarballs status.

Generated by Claude Code