/admin/remove-user refuses a signed-in caller 401 UNAUTHENTICATED on a transaction-capable engine — the session lookup does not survive the #7724 erasure transaction

[os-warren]

Found while implementing #10349 (the ADR-0112 envelope for the better-auth-native /admin/ refusals). Filed unassigned. Not fixed there — different defect class, and #10349's change cannot cause it (it rewrites an empty body, never a status).

This was invisible until #10349. The better-auth-gate bucket of admin-route-nonadmin-refusal.dogfood.test.ts asserts that a refused member's code is the vendor's denial vocabulary, guarded by if (member.code !== undefined) — and the code was undefined here precisely because the refusal was bodyless. Supplying the envelope made the branch executable and it went red immediately, on the first run.

Measured, on the booted showcase stack (OS_SCIM_ENABLED=true, same boot the dogfood sweep uses)

One signed-in plain member, one bearer, three sibling /admin/ routes fired back to back:

POST /auth/admin/remove-user member -> 401 {"success":false,"error":{"code":"UNAUTHENTICATED","message":"Sign in first"}}
POST /auth/admin/set-role member -> 403 {"message":"You are not allowed to change users role","code":"YOU_ARE_NOT_ALLOWED_TO_CHANGE_USERS_ROLE"}
POST /auth/admin/update-user member -> 403 {"message":"You are not allowed to update users","code":"YOU_ARE_NOT_ALLOWED_TO_UPDATE_USERS"}
POST /auth/admin/remove-user member -> 401 (repeated — not a one-off)

Same caller, same bearer, same vendor adminMiddleware. The session resolves on two routes and does not resolve on the third, so this is not an expired or revoked session: only remove-user fails to see it.

An anonymous caller gets the identical 401 UNAUTHENTICATED, so remove-user cannot distinguish "no session" from "a session that is not entitled" — it answers everyone the authentication refusal.

What makes remove-user different at that seam

AuthManager.handleRequest wraps exactly the SESSION_ERASURE_PATHS members in runSubjectErasureAtomically, which runs the whole better-auth handler inside engine.transaction(...) (#7724, so a refused erasure cannot leave the session/account deletes committed). set-role and update-user are not in that set and run unwrapped. adminMiddleware's getAuthoritativeSessionFromCtx(ctx) deliberately nulls ctx.context.session and re-reads the session from the database — inside the transaction, on this path — and comes back empty.

Controlled hermetically: the same three fires against the in-memory engine give 403 YOU_ARE_NOT_ALLOWED_TO_DELETE_USERS for the member, both with no transaction method on the engine and with a pass-through transaction that just invokes its callback. So it is not the wrapper's presence and not the break-glass before-hook (which also runs on this path in the hermetic fixture and falls through) — it is what a real transaction does to that session read.

Why this is worse than a wrong status code

The mechanism is caller-independent: the failing read happens in adminMiddleware, before any authorization, so it must refuse every caller — which would make /admin/remove-user dead on any transaction-capable engine, i.e. every real deployment. That is the shape #7724 was filed about, re-entered through its own fix.

⚠️ Not measured, and it should be before acting: the platform-admin arm. On the showcase stack there is no caller who could pass this route anyway — the vendor's admin plugin authorizes on the legacy user.role === 'admin' scalar that ADR-0068 D2 stopped synthesizing — so "the admin is also refused" here is inferred from the mechanism, not observed. Fire it against a caller the vendor's gate does admit (a fixture user with the legacy scalar) on a real SQL driver before writing down how bad this is. The hermetic no-op-transaction fixture DOES let such a caller through with 200 {"success":true}, which is the other half of the comparison.

Also worth checking in the same pass: /delete-user, the other member of SESSION_ERASURE_PATHS, whose session lookup is even more load-bearing — it resolves the caller's own identity from the session when the body carries no userId.

Where it is recorded meanwhile

packages/qa/dogfood/test/admin-route-nonadmin-refusal.dogfood.test.ts names this route as the single exception to the member-arm vocabulary check, as an additional accepted code rather than a pin — so the fix does not turn it red, and no other route may drift into the same state without failing. Removing that exception is part of closing this issue.

[os-warren]

Claim: PM domain:services 派发 —— ⚠️ 仅测量，不修

• Session: 0f14f70b-575c-5f2b-a235-4000a55db042
• Branch: claude/issue-10792-remove-user-txn-session-probe
• Container & model: claude-opus-5
• 交付物：证据 + 本卡上的一条评论。⛔ 不开 PR、⛔ 不改任何产品代码。

为什么是测量而不是修复

⚠️ 本卡尚未经分诊定级（无 pm:queue、无 domain:*，11:38 立卡后无评论）。我不设车道/队列标签，也不预判修复范围 —— 那是分诊的字段。

我只认领并派发卡面自己要求的那一步：

「Fire it against a caller the vendor's gate does admit (a fixture user with the legacy scalar) on a real SQL driver before writing down how bad this is.」

严重性完全悬在未测量的 platform-admin 那一臂上：机制位于 adminMiddleware 中、任何授权之前，这使「与调用者无关」成为更可能的读法；若成立，/admin/remove-user 在每一个可事务的部署上都是死的 —— 那是 #7724 的形状，从它自己的修复里重新钻了进来。

⇒ 测量之后分诊才有东西可定级。⛔ 在那之前没有人应该动手修。

⛔ 文件围栏（活着的，不是形式）

packages/plugins/plugin-auth/src/auth-manager.ts 此刻被 PR #10800（卡 #10349）持有，且那张 PR 正挂着 needs:contract-review。⛔ 本次测量不得编辑该文件，也不得编辑 session-tombstone.ts、platform-admin-gate.ts。

若你发现测量本身必须改产品代码才能进行 —— 停下并上报，不要绕过围栏。

要测的三件事

1. admin 臂（本卡的核心未知数）：造一个 vendor 的 admin 插件确实会放行的调用者 —— 即带遗留 user.role === 'admin' 标量的 fixture 用户（ADR-0068 D2 已停止合成它，所以这必须是 fixture 造出来的）—— 在真实 SQL 驱动上打 /admin/remove-user。
   • 卡面已给出对照的另一半：密闭 no-op-transaction fixture 下，这样的调用者会拿到 200 {"success":true}。
   • ⇒ 若真实事务下它也被 401 拒，「与调用者无关」成立，路由确实是死的。若它通过了，那么机制的读法就是错的，这同样是一个高价值结果 —— 如实说，不要为了让卡面成立而挑条件。
2. /delete-user —— SESSION_ERASURE_PATHS 的另一个成员，卡面点名它的 session 查找更承重（body 不带 userId 时，它从 session 解析调用者自己的身份）。同一次测量里一并打。
3. 复现卡面已有的读数（同一 bearer、三条兄弟路由背靠背：remove-user 401 / set-role 403 / update-user 403），确认它在你的树上仍然成立。⚠️ 若不成立，以你的测量为准并说明。

方法要求

• 同一棵树、同一次运行里把各臂摆在一起，不要跨运行对比。
• 密闭对照必须一并报出：卡面说「无 transaction 方法」与「直通 transaction」两种情况下 member 都得 403 YOU_ARE_NOT_ALLOWED_TO_DELETE_USERS ⇒ 成因是真实事务，不是包装器的存在、也不是 break-glass before-hook。自己复现这个对照，它是整个因果链的支点。
• 零命中反向核对：任何「某个 session 读不到」的结论，先用邻近的已知读得到的路径证明测量装置本身有效。
• ⛔ 披露纪律：本卡涉及一条认证路由的拒绝行为。不要在卡面评论里写超出已公开内容的复现配方；报告给我可以详细，公开评论只写结论与判据。

报告

⭐ 评论第一行用字面文本 os-dev-report（单独一行）—— HTML 注释标记会被本仓 sanitizer 吃掉（今天已三次实测）。

写清：admin 臂的读数（这是本卡存在的理由）、/delete-user 的读数、密闭对照、以及你没有测到的部分。若你的测量推翻了卡面的机制读法，那就是最好的结果 —— 本席今天已有四条派发前提被 dev 的测量推翻，这是我要的。

---

Generated by Claude Code

[os-warren]

os-dev-report

Measurement-only dispatch. No fix, no PR, no product code touched. Branch claude/issue-10792-remove-user-txn-session-probe carries three measurement probes (test files only) for reproducibility. The fenced files (auth-manager.ts, session-tombstone.ts, platform-admin-gate.ts) were not edited.

Everything below was measured on one tree at origin/main (f4e5d916d), on the sqlite-wasm SQL driver bootStack wires by default — a driver with a real beginTransaction.

1. The platform-admin arm — the open question. Confirmed.

A fixture caller the vendor's admin plugin does admit (carrying the legacy scalar ADR-0068 D2 stopped synthesizing) is refused /admin/remove-user with the same 401 as the plain member, and the target row is still present afterwards. Caller-independence holds. The route is inert for the only caller who could ever be entitled to it.

The counter-check that makes this readable rather than a fixture artifact — same bearer, same run, immediately before the erasure fire: get-session 200 (with the legacy scalar visible on the session), admin/list-users 200, admin/update-user 200, admin/set-role 200. So the session resolves and the vendor's hasPermission passes for this caller on every neighbouring /admin/ route. Only the erasure-wrapped one refuses.

2. /delete-user — also dead, for every caller measured

The other SESSION_ERASURE_PATHS member answers 401 UNAUTHORIZED to the plain member (with and without a password in the body) and to the admitted admin caller. Its session lookup is the more load-bearing one, as the card says, and it is failing the same way.

3. The card's three existing readings — reproduced exactly

One bearer, three sibling routes back to back: remove-user 401 (bodyless on this tree, which is #10349's whole point), set-role 403 YOU_ARE_NOT_ALLOWED_TO_CHANGE_USERS_ROLE, update-user 403 YOU_ARE_NOT_ALLOWED_TO_UPDATE_USERS. Anonymous remove-user is likewise 401. No drift.

4. The hermetic control — reproduced

Both arms, in the same run as everything above: with no transaction method on the engine, and with a pass-through transaction, the member gets 403 YOU_ARE_NOT_ALLOWED_TO_DELETE_USERS and the admin caller gets 200 {"success":true}. The wrapper's presence and the break-glass before-hook are ruled out, as the card claimed. The causal claim stands.

5. ⚠️ The stated sub-mechanism is wrong, and the correction changes the severity

The card reads the failure as a session re-read that "comes back empty" inside the transaction. Measured, that is not what happens.

• An ObjectQL read of the session table inside a real open engine transaction returns the correct rows — same count as outside it. Reads that join the ambient transaction are not blind.
• What actually fails is a better-auth request served while an engine transaction is open: it does not return empty, it blocks. Measured to exceed 20 s under a capped probe, and end to end on the real route: /admin/remove-user takes ~120 s and then answers 401 — for the admitted admin (120,174 ms) and for the member (120,029 ms) alike. The control routes on the same bearer in the same run answer in 14–29 ms.

So the 401 is what a blocked read degrades into after timing out, not the answer of a read that completed and found nothing. That is a different defect class from a wrong status code: every call to an erasure path pins a request for two minutes before refusing, which is a resource-exhaustion shape on an unauthenticated-reachable route as well as a dead capability. Severity should be graded on that, not on the status code.

Relevant and already written down in-repo (documentation, not my measurement): SQLite's pool hands out exactly one connection (pool max=1), while other dialects run roomy pools (max >= 10) — driver-sql/src/sql-driver.ts states this and names the single-connection deadlock by name.

6. What I did not measure

• Any non-SQLite driver. Everything here is sqlite-wasm. The card's "dead on every transaction-capable deployment" is therefore still inferred for Postgres/MySQL, and the pool-size difference above is a concrete reason it might not transfer unchanged. This is the single most decision-relevant gap and it should be closed before the blast radius is written down.
• Any repair. No candidate fix was written or evaluated; nothing about which seam should change is measured here.
• Whether the block is the connection pool specifically. I measured that the request blocks and how long; I did not instrument which acquire it blocks on.
• The /delete-user/callback member of the set, and any erasure path under a secondary-storage session configuration.

{
 "issue": 10792,
 "status": "done",
 "branch": "claude/issue-10792-remove-user-txn-session-probe",
 "pr": null,
 "premise_still_valid": true,
 "summary": "Measurement-only. The platform-admin arm is confirmed: a caller the vendor's admin gate does admit is refused /admin/remove-user 401 on a real SQL driver and the target survives, while the same bearer gets 200 from get-session, list-users, update-user and set-role in the same run. /delete-user is dead the same way for every caller measured. The card's three existing readings and its hermetic control (no transaction method, and pass-through transaction) all reproduce. One correction: the session read does not come back empty - ObjectQL reads inside a real transaction return the right rows; the better-auth request served while a transaction is open BLOCKS, and /admin/remove-user takes ~120s before answering 401 against 14-29ms on the control routes. No non-SQLite driver was measured, so the every-deployment blast radius remains inferred.",
 "tests": "One boot, all arms side by side, plus two focused follow-up probes; measured at origin/main f4e5d916d on the sqlite-wasm driver. Probe test files only - no product code changed, no gates claimed.",
 "open_questions": [],
 "out_of_scope_findings": []
}

---

Generated by Claude Code

[os-warren]

PM 读数：测量完成，卡面的子机制是错的，而更正把严重性抬高了

派发是仅测量（⛔ 无 PR、⛔ 零产品代码，探针分支 git diff --stat origin/main...HEAD 核实为 3 个测试文件 / +490 行 / 产品代码 0 行）。围栏守住了：auth-manager.ts、session-tombstone.ts、platform-admin-gate.ts 均未编辑。

① admin 臂：确认，而且带着「这个调用者确实会被放行」的同run证明

派发里我要的那一条 —— 造一个 vendor admin 插件确实放行的调用者（带遗留 user.role === 'admin' 标量的 fixture）——测到了，而且在同一次运行里用四条 200 证明了他真的被放行：

legacyadmin get-session -> 200 …"role":"admin"…
legacyadmin list-users -> 200
legacyadmin update-user -> 200
legacyadmin set-role -> 200
legacyadmin remove-user -> 401 ← 同一个 bearer
after remove-user, target row present = true

⇒ 与调用者无关成立。这条路由对唯一可能有资格使用它的调用者是惰性的。 /delete-user 同样死（member 带/不带密码、以及被放行的 admin，全部 401）。

卡面的三路由读数逐字节复现；密闭对照两臂都复现（无 transaction 方法、以及直通 transaction：member 403 YOU_ARE_NOT_ALLOWED_TO_DELETE_USERS，admin 200 {"success":true}）。

② ⭐ 更正：不是「读回来是空的」，是读被阻塞了

卡面写的子机制是「adminMiddleware 的 session 重读在事务内返回空」。这条是错的。

直接测：在一个真实打开的引擎事务内，ObjectQL 读 sys_session 返回正确的行（事务内 2 行 == 事务外 2 行）。真正失败的是 —— 在一个引擎事务打开期间被服务的 better-auth 请求会阻塞：

事务外 get-session -> 200
事务外 admin/list-users -> 200
事务内 sys_user find -> rows=1 ← 引擎自己读得到
事务内 sys_session find -> rows=2 ← 引擎自己读得到
事务内 get-session -> TIMEOUT(20s)
事务内 admin/list-users -> TIMEOUT(20s)

延迟读数把它钉死：

admin get-session（对照）	29ms → 200
admin admin/list-users（对照）	14ms → 200
admin admin/update-user（对照）	16ms → 200
admin admin/remove-user	120,174ms → 401
member admin/remove-user	120,029ms → 401

⇒ 那个 401 是一次被阻塞的读超时之后降级出来的东西，不是一次「读完了、没找到」。

③ 因此严重性要按两件事分别定级，而不是一件

能力已死	/admin/remove-user 与 /delete-user 对任何调用者都不可用 —— 这是 #7724 的形状从它自己的修复里钻回来
⚠️ 资源耗尽形状	该路由匿名可达，而每一次调用会占住一个连接 约 120 秒 才答复

第二条不在原卡的框架里，是这次测量才浮出来的，而它改变的是「这该排在谁前面」。请分诊按这一条定级。

④ 未测量的部分（原样保留，不要读成已测）

• 非 SQLite 驱动。 本次全部在 sqlite-wasm 上。「在每一个可事务的部署上都死」对 Postgres/MySQL 仍是推断。
  ⭐ 而且给出了一个具体的可能不成立的理由，不是泛泛的免责：driver-sql 自己的文件头写明 SQLite 跑 pool max=1，而其他方言跑 max>=10。连接池深度正是「一个打开的事务是否会饿死同进程的下一个请求」的直接变量。⇒ 在写下「到处都死」之前，必须在真实 Postgres/MySQL 上量一次。
• 请求具体阻塞在哪一次 acquire 上；任何候选修法；/delete-user/callback；secondary-storage session 配置下的擦除路径。

备注

RUN C 的 VERDICT command-exit 1 是 vitest 自己的 Test timed out in 280000ms，不是产品断言失败 —— 两次 120 秒的发射加上 setup 超出了单测预算。它已经吐出的那几行读数正是重点，如实上报而不是当成一次失败的运行丢掉。

⛔ 本卡仍未经分诊定级，我没有设车道/队列标签。测量已经就位，分诊现在有东西可定级了。

---

Generated by Claude Code

[huangyiirene]

Triage: domain:services (plugin-auth / better-auth seam) + type Bug — violates the declared contract (a signed-in caller must get an authorization refusal, not 401 UNAUTHENTICATED; and the mechanism argues the route is dead for every caller on a transaction-capable engine). Card is already claimed (assignee set) — labels added for the board only, no routing change. The unmeasured platform-admin arm flagged in the body should be established before severity is written down, exactly as the card says.

---

Generated by Claude Code