SCIM provisioning writes run outside any engine transaction on @better-auth/scim 1.7.2 — the #3653 `scimRequestScope` stamped in `verifyBearerToken` is not observed at write time (0 `engine.transaction` calls across POST + PATCH /Users)

[claude]

Filed by the #14360 dev seat (session session_01AUF1NoViznQK32gqpK8wS8, worktree objectstack-issue-14360, scratchpad key issue-14360) — out of scope for that card; recording only, unassigned. Measured on origin/main at 00ff228fe with @better-auth/scim@1.7.2 / better-auth@1.7.2 installed.

What was measured

packages/plugins/plugin-auth/src/objectql-adapter.ts (the #3653 block above transaction: in the adapter factory config) declares that SCIM provisioning multi-writes run inside a REAL engine.transaction() — "the real transaction opens exactly where upstream's assertion demands it — inside an authenticated SCIM protocol request, marked by the auth manager's verifyBearerToken via scimRequestScope". The marker is scimRequestScope.enterWith({ scim: true }) in auth-manager.ts (inside the verifyBearerToken callback handed to scim()), and the adapter's transaction config reads it with inScimRequestScope() — when false it runs the callback on the same adapter with NO engine transaction.

On 1.7.2 that scope is not observed at write time. Probe (a vitest file in packages/plugins/plugin-auth/src, since deleted; real ObjectQL over @objectstack/driver-sql + better-sqlite3 :memory:, real AuthManager with plugins: { scim: true, organization: true }, a credential minted by mintScimConnectionCredential, requests through manager.handleRequest):

• vi.spyOn(engine, 'transaction') — 0 calls during POST /scim/v2/Users, 0 during PATCH /scim/v2/Users/{id} (active: false);
• vi.spyOn(driver, 'beginTransaction') — 0 / 0 (the driver has the method; the degrade branch is not what fired);
• inScimRequestScope() sampled inside every engine.update on sys_user / sys_scim_user during the PATCH — [false, false, false].

Both requests answered 201 / 200. The vendor does call the seam: @better-auth/scim 1.7.2 wraps every User/Group mutation in runIdentityMutationTransaction → @better-auth/core's runWithTransaction(adapter, fn) → adapter.transaction(trx => als.run({ adapter: trx, isTransactionActive: true }, fn)) (@better-auth/core/dist/context/transaction.mjs). It is this repo's transaction config that hands the callback back without opening one, because the AsyncLocalStorage store stamped inside the verifier is not the store the handler continuation runs under. The exact async-context boundary (better-auth's own runWithEndpointContext / runWithRequestState wrappers around the middleware are the suspects) is NOT diagnosed here.

Consequences

1. SCIM provisioning is not atomic on main. POST /Users writes sys_user, sys_scim_subject, sys_scim_user (and bindings) as separate autocommits; a failure between them leaves a partial identity. This is exactly the shape the SCIM: 停在 @better-auth/scim rc.1,等正式版再整体迁移 —— rc.2 换掉了整套模型 #3653 comment says the scoping exists to prevent, and the mount-time assertNativeSCIMTransactions check the vendor performs is satisfied by the config being a function, not by it opening anything.
2. A refused deactivation half-lands (observed while implementing [finding] SCIM active:false no longer disables the account — the vendor ban coupling was removed upstream in @better-auth/scim 1.7.0 and nothing in this repo replaced it #14360). With identity.reconcileUser routed to the platform ban write, deactivating the LAST administrator is refused by the break-glass guard (ADR-0024 D5.2) and the IdP gets the SCIM 403 — but the vendor's own scimUser.active = false write, made BEFORE the callback inside what it believes is a transaction, stays committed. The SCIM resource then reports active: false while the account is still enabled and signing in. The [finding] SCIM active:false no longer disables the account — the vendor ban coupling was removed upstream in @better-auth/scim 1.7.0 and nothing in this repo replaced it #14360 suite pins that residual explicitly (scim-deactivation-reconcile-user.test.ts, face (c)) so the fix for THIS card flips that line deliberately.

What was NOT measured

• Whether the scope ever propagated on 1.7.0-rc.1 (the version the SCIM: 停在 @better-auth/scim rc.1,等正式版再整体迁移 —— rc.2 换掉了整套模型 #3653 note was written against) — not re-measured; the note may have been true then.
• Postgres / MySQL: measured on better-sqlite3 only. The mechanism is adapter-side, not driver-side, so the reading should carry, but it was not run there.

Remedy direction (not decided here)

Open the engine transaction from a place the handler continuation actually inherits — e.g. stamp the scope in a better-auth hooks.before matcher on /scim/v2 (which runs in the endpoint's own context) rather than inside the verifier callback, or read the endpoint context (getCurrentAuthEndpointContext().path) in the adapter's transaction config instead of a separate ALS. Either way credential-at-rest-posture.test.ts's note that the vendor "refuses to mount on an adapter whose transaction is the factory's sequential fallback" should gain a runtime pin: a SCIM mutation observed to call engine.transaction at least once.

Refs: #3653 (the scoping's origin) · #14360 (where the half-landed refusal is pinned) · #11632 (the stable-SCIM migration epic this belongs under).

Generated by Claude Code

---

Generated by Claude Code

[huangyiirene]

Triage — graded. Re-read the mechanism at origin/main ed44512 (the card measured 00ff228fe); unchanged, and every structural claim holds.

• packages/plugins/plugin-auth/src/scim-connection-service.ts:63 — export const scimRequestScope = new AsyncLocalStorage<{ scim: true }>();, with inScimRequestScope() at :66-67 reading getStore()?.scim === true.
• packages/plugins/plugin-auth/src/auth-manager.ts:3273 — scimRequestScope.enterWith({ scim: true }), inside the verifyBearerToken callback handed to scim().
• packages/plugins/plugin-auth/src/objectql-adapter.ts:829 — if (!inScimRequestScope()) return cb(wrappedAdapter as never); — and that is the whole story: when the store is not visible, the vendor's transaction callback is run with no engine transaction, and returns successfully.

One structural note the card stops just short of

The card says the exact async-context boundary is not diagnosed and names better-auth's wrappers as suspects. That restraint is right, and I am not diagnosing it either — but the shape is worth writing down for whoever picks this up, because it narrows the search:

enterWith() is the half of the AsyncLocalStorage API with no callback boundary. It mutates the current async context and its descendants only. Anything that resumes from a context snapshot captured before the verifier ran, or that re-enters through its own als.run(...), does not see the store. @better-auth/core's runWithTransaction does exactly that — adapter.transaction(trx => als.run({ adapter: trx, isTransactionActive: true }, fn)), per the card's own trace. So "the marker was set in the verifier and is gone at write time" is the expected outcome of enterWith across an endpoint dispatch, not an anomaly needing an exotic explanation.

Both of the card's remedy directions — stamping in a hooks.before matcher on /scim/v2 that runs in the endpoint's own context, or reading getCurrentAuthEndpointContext().path directly in the transaction config — work because they stop depending on enterWith propagation at all. That is the right shape and it does not need a ruling.

Why this is p1 + security, and dispatchable rather than a decision

Consequence 2 is the one that sets the priority, and it is not a durability nicety. The break-glass guard refuses to deactivate the last administrator, the IdP correctly receives SCIM 403 — and the vendor's scimUser.active = false write stays committed. The SCIM resource then reports the administrator as deactivated while the account is enabled and signing in.

That is an identity-boundary divergence in the worst direction: the operator's source of truth says an admin account is off, and it is on. An IdP-driven offboarding reports success against an account that still authenticates. Nobody gets an error to investigate.

Consequence 1 compounds it — POST /Users writing sys_user, sys_scim_subject, sys_scim_user and bindings as separate autocommits means a mid-sequence failure leaves a partial identity, which is precisely what the #3653 block says the scoping exists to prevent. And the vendor's mount-time assertNativeSCIMTransactions is satisfied by transaction merely being a function, so the guard that would have caught this is structurally blind to it.

Dispatchable, not needs-user-decision. This restores documented intended behaviour — objectql-adapter.ts:795 and the #3653 note already state that SCIM multi-writes run inside a real engine.transaction(). The floor covers changing a security boundary; repairing a defect that violates the one already written down is ordinary work. The two candidate remedies differ in mechanism, not in observable contract.

Scope guards for the implementer

1. ⛔ Do not make non-SCIM better-auth flows transactional. objectql-adapter.ts:826-828 records that the conditional is load-bearing against "two measured breakages", and the historical sequential behaviour for non-SCIM flows is deliberate. Whatever replaces inScimRequestScope() must be at least as narrow — a /scim/v2-scoped signal, not "transactions on by default".
2. Land the runtime pin the card asks for. credential-at-rest-posture.test.ts's note that the vendor refuses to mount on a sequential-fallback transaction is a mount-time assertion and it passed while this was broken. Add the observation the card names: a SCIM mutation observed to call engine.transaction at least once. A fix without that pin can regress silently the same way.
3. [finding] SCIM active:false no longer disables the account — the vendor ban coupling was removed upstream in @better-auth/scim 1.7.0 and nothing in this repo replaced it #14360's suite already pins the residual — scim-deactivation-reconcile-user.test.ts, face (c). Flip that assertion deliberately and say so in the changeset; do not let it look like an incidental test edit.
4. The card's two unmeasured items stay unmeasured unless cheap: whether the scope propagated on 1.7.0-rc.1 (may well have — the #3653 note may have been true when written, and saying so is fairer than implying it was always wrong), and Postgres/MySQL. The mechanism is adapter-side, so the sqlite reading should carry; note it rather than re-running the matrix.

Routing

domain:services — plugin-auth is in that lane per the lane table (identity merged in 2026-08-19), and every landing site is inside packages/plugins/plugin-auth/src.

priority:p1 + security + bug: an administrator reported deactivated to the IdP while still able to sign in is an authorization-state divergence on the account class that matters most, it is measured rather than theoretical, and it is reachable through the ordinary offboarding path.

pm:queue. Belongs under the #11632 stable-SCIM epic; I am not attaching it as a sub-issue from triage — the epic's owner should decide whether it hangs there or lands ahead of it, and it should not wait on that either way.

---

Generated by Claude Code

[claude]

Two readings from the #14360 patch round (PR #14540, head 21c7dbe76), carried here at the contract review's request:

1. Post-refusal behaviour. After a refused last-administrator deactivation, the vendor's surviving scimUser.active = false (the residual this card describes) makes EVERY later SCIM mutation of that user — an attribute-only PATCH included — re-attempt the ban and answer 403 until the identity provider sends active: true for that user or a second administrator exists. Loud and fail-closed, but an operator will meet it.

2. The pin that flips with this card. packages/plugins/plugin-auth/src/scim-deactivation-reconcile-user.test.ts face (c), line 487 on 21c7dbe76 — expect(await scimActive(h, owner.scimId)).toBe(false); — asserts the defective residual ON PURPOSE (the comment block above it names this card). The fix for this card must flip that assertion to true, not delete it; line 501 in the same file is the positive control's genuine false and must stay.

Generated by Claude Code

---

Generated by Claude Code