Filed unassigned by the objectstack-ai/objectui#5217 dev (session session_01RV6yuVCxymHYE16PL9vQkE) as an out_of_scope_findings item. Not fixed here, not reached for — objectstack-ai/objectui#5217 scopes this half explicitly out of objectui.
Why this card exists: a tracking gap, not a new discovery
The defect itself is old and was always named. What is new is that nothing tracks it any more:
So the half fell between the two cards. A search of open issues in this repo for the silent-success shape returns nothing (the two sys_session neighbours, #7826 and #7732, are different defects).
The defect
An action that identifies no record still answers { status: true }. Measured shape: revoke_session on sys_session sends its token param, better-auth's revoke-session uses it as a match key, matches zero rows, deletes nothing — and reports success. A security control that no-ops while telling the operator it worked.
The client-side half is now closed: objectstack-ai/objectui#4670 harvests every declared recordIdField into the grid projection, and refuses before dispatch when the row cannot supply the key, so the console no longer sends an under-specified revoke. That removes the route that surfaced this — it does not make the server's answer correct. Any other caller reaching /api/v1/auth/revoke-session with a non-matching token still gets { status: true }.
Note for whoever scopes it
sys_session.token carries internal: true since #7823 (merged, PR #7996), so it is stripped from data-API result rows regardless of projection. The console's Revoke Session therefore now hits the refusal path rather than the false-success path. A server-resolved revoke mechanism — the action naming the record by id and the server resolving the token — is the other piece of the remainder, and it is a separate scoping question from the answer-shape defect above.
Establishment level, stated honestly: the { status: true } behaviour is read from code and carried forward from #8018's original measurement. The end-to-end was not run by this filer.
Generated by Claude Code
Filed unassigned by the
objectstack-ai/objectui#5217dev (sessionsession_01RV6yuVCxymHYE16PL9vQkE) as anout_of_scope_findingsitem. Not fixed here, not reached for — objectstack-ai/objectui#5217 scopes this half explicitly out of objectui.Why this card exists: a tracking gap, not a new discovery
The defect itself is old and was always named. What is new is that nothing tracks it any more:
recordIdFieldis not harvested into the grid's$select—sys_session"Revoke Session" reports success and revokes nothing #8018 was the card that carried it. Its ACCEPT (2026-08-15) recorded the remainder as staying in this repo, and the post-merge pairing comment restated it.recordIdFieldis not harvested into the grid's$select—sys_session"Revoke Session" reports success and revokes nothing #8018 was closed asmovedtorecordIdFieldis not harvested into the grid's$select— "Revoke Session" reports success and revokes nothing objectui#5217. The move comment says "Two halves stay with this repo" — but closingrecordIdFieldis not harvested into the grid's$select—sys_session"Revoke Session" reports success and revokes nothing #8018 is what was tracking them.recordIdFieldis not harvested into the grid's$select— "Revoke Session" reports success and revokes nothing objectui#5217, the destination, says the silent-success half is server-side and therefore not in this repo.So the half fell between the two cards. A search of open issues in this repo for the silent-success shape returns nothing (the two
sys_sessionneighbours, #7826 and #7732, are different defects).The defect
An action that identifies no record still answers
{ status: true }. Measured shape:revoke_sessiononsys_sessionsends itstokenparam, better-auth'srevoke-sessionuses it as a match key, matches zero rows, deletes nothing — and reports success. A security control that no-ops while telling the operator it worked.The client-side half is now closed: objectstack-ai/objectui#4670 harvests every declared
recordIdFieldinto the grid projection, and refuses before dispatch when the row cannot supply the key, so the console no longer sends an under-specified revoke. That removes the route that surfaced this — it does not make the server's answer correct. Any other caller reaching/api/v1/auth/revoke-sessionwith a non-matching token still gets{ status: true }.Note for whoever scopes it
sys_session.tokencarriesinternal: truesince #7823 (merged, PR #7996), so it is stripped from data-API result rows regardless of projection. The console's Revoke Session therefore now hits the refusal path rather than the false-success path. A server-resolved revoke mechanism — the action naming the record byidand the server resolving the token — is the other piece of the remainder, and it is a separate scoping question from the answer-shape defect above.Establishment level, stated honestly: the
{ status: true }behaviour is read from code and carried forward from #8018's original measurement. The end-to-end was not run by this filer.Generated by Claude Code