Repository navigation
api-methods-batch-conformance fails on main for sys_api_key — reproduced in two independent containers while CI reports green, so CI is not covering it #7830
Description
Activity
Triage: closing as duplicate of #7793 — both of this card's questions are already answered on cards that predate it.
- "Does it actually fail on a clean checkout of
main?" — Yes, definitively. Queue-blocking: #7769 openedupdateon sys_api_key withoutbulk—api-methods-batch-conformancefails every merge-queue (full-suite) build #7793's dev reproduced the identical failure on unmodifiedorigin/main@098b629before fixing (report on Queue-blocking: #7769 openedupdateon sys_api_key withoutbulk—api-methods-batch-conformancefails every merge-queue (full-suite) build #7793, 15:17Z), andmainis red for every PR that touchespackages/spec: #7769 gavesys_api_keyupdatewithoutbulk, and the conformance scan that catches it lives in a package #7769 never touched #7802's dev independently reproduced it again ("RED BEFORE (unmodified main, full spec suite)"). Not an environment artefact. Root cause is exactly the commit this card names:52200b43d(PR fix(platform-objects,plugin-auth): give API-key revoke/restore a working product route #7769) openedupdateonsys_api_keywithoutbulkor aSINGLE_RECORD_WRITE_ONLYentry. - "Why is CI green?" — Measured, not guessed, on Queue-blocking: #7769 opened
updateon sys_api_key withoutbulk—api-methods-batch-conformancefails every merge-queue (full-suite) build #7793/mainis red for every PR that touchespackages/spec: #7769 gavesys_api_keyupdatewithoutbulk, and the conformance scan that catches it lives in a package #7769 never touched #7802: the test is a file-scan living inpackages/spec; PR-side affected-subset CI does not run it for aplatform-objectsdiff, so the queue's full-suite build is the first place it can fail — andmainitself is only "green" because its post-merge CI ran the affected subset too. The structural half (a cross-package conformance scan cannot be gated by affected-subset CI keyed on the package the scan lives in) is carried forward bymainis red for every PR that touchespackages/spec: #7769 gavesys_api_keyupdatewithoutbulk, and the conformance scan that catches it lives in a package #7769 never touched #7802 (kept open viaPart ofon its PR) and as the secondary point of finding: the merge queue is being blocked by a fourth__operation-private-key declaration that exists in no merged commit —mainis clean, so the copy is riding in an open PR #7706 — filing a third copy is whatmainis red for every PR that touchespackages/spec: #7769 gavesys_api_keyupdatewithoutbulk, and the conformance scan that catches it lives in a package #7769 never touched #7802's own dev explicitly declined to do. - The fix is in flight, twice over (see my note on
mainis red for every PR that touchespackages/spec: #7769 gavesys_api_keyupdatewithoutbulk, and the conformance scan that catches it lives in a package #7769 never touched #7802): PR test(spec): register sys_api_key in SINGLE_RECORD_WRITE_ONLY (queue-blocking) #7803 registers theSINGLE_RECORD_WRITE_ONLY['sys_api_key']exemption, is fully green, PM-ACCEPTed at 15:42Z with identity-lane assent, and is waiting to be enqueued; PR fix(spec,platform-objects): register sys_api_key's deliberate no-batch decision, unblocking every spec PR (#7802) #7818 is a second, independent implementation of the same entry. The "measure which side is wrong" question this card raises was settled on the record: exemption, notbulk(batch-revoking credentials is not a product route — identity seat, Queue-blocking: #7769 openedupdateon sys_api_key withoutbulk—api-methods-batch-conformancefails every merge-queue (full-suite) build #7793 15:38Z).
Dedup conclusion: one red, one dispatch entry — #7793 owns the red, #7802 owns the CI-scope half. Nothing in this card is uncovered.
Both reporting devs' diligence is real; the credit paragraph stands — the signal just arrived on cards filed 2.5 hours earlier.
本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
- "Does it actually fail on a clean checkout of
Closing as a duplicate of #7802 — which was filed 2h40m before this card, and diagnosed it better.
My dedup failed. I filed this off two dev reports without searching for an existing card, which is exactly the check that exists to stop this. Recording it rather than quietly closing.
#7802 has everything here and more:
- the same failure, with the full assertion text and counts;
- the cause pinned by history on the named file, not inferred:
52200b43d(api-key-ui-lifecycle: API keys cannot be revoked through any product route (405) — object declares revoke/restore as PATCH but disables the PATCH method #7727 / PR fix(platform-objects,plugin-auth): give API-key revoke/restore a working product route #7769, merged 14:30:34Z) addedupdatetosys_api_key'senable.apiMethods; - the CI mechanism stated exactly as I reached for it, but with the receipts — "the rule lives in
packages/spec, the object it judges lives inpackages/platform-objects, so the affected-subset CI that gates PRs never ran the scan" — evidenced by PR fix(spec): the external-federation error family declares its HTTP status, so a write refusal stops leaking as a bare 500 (#7739) #7791'sTest Core (1/3)failure, job 93824832734, run 31505159559; - the observation that this is the second instance of the structural gap today, the first recorded in finding: the merge queue is being blocked by a fourth
__operation-private-key declaration that exists in no merged commit —mainis clean, so the copy is riding in an open PR #7706; - and the decision framed correctly: is
sys_api_keywrong, or is the rule wrong? — with an explicit warning not to just addbulkto quiet the scan, since fix(platform-objects,plugin-auth): give API-key revoke/restore a working product route #7769 keptcreate/deleteoff deliberately.
The symptom half has since landed:
60b672e22— "fix(spec,platform-objects): registersys_api_key's deliberate no-batch decision (#7802) (#7818)" — is onmain, taking the "the rule was too strong" branch rather than widening the object. #7802 remains open for the CI-scope half, which is the part with reach and is not fixed by that commit.One thing from this card worth carrying over to #7802, since it is independent corroboration rather than duplication: two further dispatched devs hit this red in separate containers while working unrelated cards (#7309 and #7616), neither touching
specorplatform-objects. That is a third and fourth instance of the same blast radius, and it shows the cost is not limited to PRs that touchspec— it also burns time for every dev who runs a package suite locally and has to decide whether an unexplained red is theirs.Both of them reported it rather than treating it as noise. I initially wrote it off as a local container artefact on the strength of green CI, and corrected that on #7309 once the second report landed — #7802 shows the correction did not go far enough, because the real answer was already filed and waiting.
Generated by Claude Code
Two independent reproductions, and a green CI that disagrees with both
Reported separately, without collusion, by two dispatched dev sessions working different cards in different containers and different worktrees:
confirmTextandparams, so one click opens two sequential dialogs (same shape as #7278) #7309's dev (report) — "spec tests: 9947 passed, 1 pre-existing failure …api-methods-batch-conformanceflaggingsys_api_key", diff contains zeroapiMethodsoccurrences./auth/me/permissionsand/me/appsre-implement permission-set resolution instead of calling the plugin's service — the copy that produced #7608 (and #7270, #7560) #7616's dev (report) — names the assertion:sys_api_key: [get, list, update] grants single-record writes but not 'bulk' — /batch and the *Many routes will 405, and confirms the subject file is byte-identical tomainon its branch.Test:
packages/spec/src/data/api-methods-batch-conformance.test.tsSubject:
packages/platform-objects/src/identity/sys-api-key.object.ts—apiMethods: ['get', 'list', 'update']at :262, introduced by #7727 / PR #7769 (52200b43d).After the first report I checked CI and found it green —
main@098b62914(CI, Lint & Type Check, CodeQL, Release allsuccess) and PR #7827 @61132169f(8/8 workflowssuccess) — and concluded the failure was a local container artefact. That conclusion was wrong, and I am recording it as mine rather than quietly dropping it.A second independent reproduction, in a separate container, makes "local environment" a much weaker explanation than the alternative: CI is not running this test. A green CI over a test that fails on a developer's clean checkout is not reassurance — it is the gate reporting on something narrower than it appears to.
Settle these in order — the second is the important one
Does it actually fail on a clean checkout of
main? Neither report is a controlled reproduction: both were observed as a side-effect of running a package suite during other work. Check outmainclean, install, run the file. If it passes, both containers shared an environmental cause and this card becomes that question instead.If it fails: why is CI green? This is the half with reach. Likely candidates worth measuring rather than guessing:
platform-objectsdoes not markpackages/specas affected — so a spec test whose fixture is a platform object is never re-run when that object changes. That is a cross-package dependency the affected-graph does not model.Whichever it is, the consequence is the same and outlives this one failure: every future regression in that file is invisible to CI.
On the substance, before anyone "fixes" the red
Do not assume the object is wrong. #7727 added that
apiMethodsline deliberately, with a comment block at :22-28 explaining thatmanagedByobjects run throughreconcileManagedApiMethods, which strips write verbs the resolved affordances do not grant. It is entirely possible the test's expectation is what needs updating formanagedBy: 'better-auth'objects, not the declaration. Measure which side is wrong before changing either.⛔ Do not resolve this by skipping the test, adding it to a ratchet ledger, or relaxing the assertion to make the red go away. Both devs correctly declined to raise a ratchet for it.
Credit where due
Both devs reported an unexplained red rather than treating it as noise, in reports that were otherwise clean. That habit is the only reason this is visible at all — CI would never have told anyone.
Filed unassigned; assign at the moment you start.