[finding] plugin-auth SCIM harnesses register no OAuth objects, so every sign-in logs a Better Auth ERROR (`back-channel logout planning failed … no such table: sys_oauth_access_token`)

[os-sales]

Filed by the #14522 dev seat (session session_01AUF1NoViznQK32gqpK8wS8, worktree objectstack-issue-14522) — out of scope for that card; recording only, unassigned. Observed on origin/main 2a2653619 merged into the #14522 branch, @better-auth/scim 1.7.2 / better-auth 1.7.2.

What was observed

Running packages/plugins/plugin-auth/src/scim-deactivation-reconcile-user.test.ts (the #14360 suite) — and the #14522 pin scim-transaction-scope.test.ts, whose harness copies the same shape — every POST /sign-in/email the tests drive prints, at ERROR level through the vendor's logger:

[Better Auth]: back-channel logout planning failed Error: The database refused to run this query for object 'sys_oauth_access_token'. The driver could not attribute the failure to any part of the request, so no verdict about the query is claimed here. ...
 [cause]: SqliteError: select * from `sys_oauth_access_token` where `session_id` = '...' limit 100 - no such table: sys_oauth_access_token

The harnesses register the identity + SCIM objects (SysUser … SysScimUser, SysJwks) but none of the OAuth objects (SysOauthApplication, SysOauthAccessToken, SysOauthRefreshToken, SysOauthConsent), while the sign-in path's back-channel logout planning reads sys_oauth_access_token for the new session. credential-at-rest-posture.test.ts registers the OAuth objects and does not emit this line. All tests pass; the line is noise, not a failure.

Why it is worth a card

• An ERROR-level line that fires on every green run trains readers to skim ERROR in exactly the suites where a real durability error would matter (the SCIM transaction seam, 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) #14522). The AGENTS.md degradation-log-level rule names this cost.
• It is a harness gap, not a product defect: production registers every platform object. But the same gap will be copied into the next SCIM harness (it already was, twice).

Remedy direction (not decided here)

Either register the four OAuth objects in the two harnesses (the posture test's AUTH_OBJECTS list is the reference), or — if the back-channel planner is meant to tolerate a deployment that never mounted the OIDC provider — ask whether an absent sys_oauth_access_token should be a discriminated benign read rather than an ERROR (the read-seam rule's isMissingTableError shape). Which of the two is right is the decision; this card only records the observation.

Refs: #14360 (the suite), #14522 (the pin that copied its harness).

Generated by Claude Code

[huangyiirene]

Triage — graded p3, finding cleared, tests, pm:queue, routed domain:services.

The one claim that decides the card, measured

You wrote "It is a harness gap, not a product defect: but production registers every platform object" and left the remedy open between (a) fix the harnesses and (b) make the planner tolerate an absent table. (a) is right, and (b) is not motivated, because the production claim holds by construction:

packages/plugins/plugin-auth/src/manifest.ts exports authIdentityObjects — the plugin's own object set — and it contains all four you name (SysOauthApplication, SysOauthAccessToken, SysOauthRefreshToken, SysOauthConsent) plus five more in the same family (SysOauthResource, SysOauthClientResource, SysOauthClientAssertion, SysDeviceCode, SysSsoProvider). Any deployment that mounts plugin-auth gets sys_oauth_access_token. There is no supported shape in which the back-channel planner reads a table that was never created.

⇒ ⛔ Do not build the isMissingTableError discrimination. It would add a benign-read branch for a state the product cannot reach, and the read-seam rule exists for seams where absence is legitimate. This one is a harness that is simply wrong about what a deployment looks like.

⭐ But do not fix it the way the card suggests either

The card offers "the posture test's AUTH_OBJECTS list is the reference". AUTH_OBJECTS in credential-at-rest-posture.test.ts is itself a hand-copied second spelling of authIdentityObjects. Adding four names to two more hand-lists gives the repo four copies of one truth, and the card's own strongest observation is that this gap "will be copied into the next SCIM harness (it already was, twice)."

Register from authIdentityObjects directly. It is already exported, already the production set, and a harness built on it cannot drift from production by construction — which is the only version of this fix that stops the third copy. If a harness genuinely needs a subset, it should subtract from that array by name, so the subtraction is visible and reviewable rather than an omission nobody can see.

Whether to also convert AUTH_OBJECTS in the posture test is the implementer's call — in scope if it is mechanical, a separate card if it turns out that test depends on its list being narrower for a reason.

Why p3

All tests pass and nothing is at risk today. What earns it a grade at all rather than a shrug is the cost you name correctly: an ERROR-level line on every green run trains readers to skim ERROR in the SCIM transaction seam specifically, which is where a real durability failure would surface. That is a slow, compounding cost, not an urgent one, and the fix is a few lines — a good p3.

Routing

domain:services — plugin-auth per the lane table (2026-08-19 merge; the former domain:identity is retired).

Files in scope: scim-deactivation-reconcile-user.test.ts (#14360) and scim-transaction-scope.test.ts (#14522). ⛔ Do not widen to other plugin-auth harnesses in this card; if the same shape is found elsewhere, measure the population first and file it with the count, the way #14628 did.

---

Generated by Claude Code