fix(scripts): complete the transparency notice in the API test harnesses - #1755
Conversation
A signed-in person must complete the current transparency notice before the server answers anything else, so the release upgrade drill's post-upgrade reads returned 428 "Complete the current transparency notice first" — the gate is right and the harness was signing in like a first-time user and then skipping the step that user takes. Both harnesses that drive the API with a dev-login session now complete the notice through the same endpoint the first-login interstitial posts to, and neither weakens the gate: the drill tolerates a release that predates the notice and a session that already accepted it, and each accepts the terms without opting into research. The browser suite's fixture already did this through the interstitial itself. Verified by running the drill locally against the v0.75.0 candidate and v0.74.0 images from the failing release run: it reproduces the reported 428 before the change and passes after it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Warning Review limit reachedNext included review available in 59 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Approved automatically: @FelixTJDietrich is listed in the REVIEW_POLICY_MAINTAINERS repository variable, which the repository treats as satisfying the review requirement. See the review policy in docs/contributor/ci-cd.mdx.
github-actions
Bot
added
the
size:M
📚 Documentation Preview
|
🧩 Storybook Preview
|
1 participant
What changed and why
upgrade-test / upgradefails in the v0.75.0 release run withThe server is right and the harness is wrong. The consent gate applies only to a request whose token
subject is an account — a person's session — and lets
GET /user,GET|PUT /user/consent, logout andrefresh through; machine callers (webhook ingest, worker registration, the agent callbacks) carry no
account subject and are not gated at all. The drill signs in through
/auth/dev-login, which mintsexactly the session the OAuth success path mints, and then does the reads a browser does. It is a
first login, and it was skipping the step every first login takes. After the upgrade, the account
seeded on v0.74.0 has no decision recorded against the new notice, which is the intended re-prompt.
So the harness completes the notice the way the interstitial does: read
GET /user/consentfor thecurrent version, then
PUT /user/consentwith the terms accepted and research participationdeclined. Nothing about the gate changes.
scripts/e2e-setup.tsseeds a live instance over the same dev-login session and hits the samegated endpoints, so it gets the same step. The browser suite already handled this —
loginAsDevAdminin
webapp/e2e/fixtures.tswalks the real interstitial — and both additions follow it in toleratingan account that has already accepted.
The drill runs against released images as well as the candidate, so it treats a 404 from
/user/consentas "this release predates the notice" and acompletedstatus as "already accepted"rather than assuming either.
How to test
Reproduced against the exact images from the failing run:
With the script from
mainthis fails with the 428 above at the post-upgrade read; with this changeit prints
Seeded previous-release upgrade passed.pnpm run formatandpnpm run checkare green.Release impact
No changeset: this changes release and E2E tooling only, no shipped code and no operator-visible
behaviour. The consent gate is untouched — the point of the change is that CI now satisfies it
instead of avoiding it.
Notes for reviewers
The interesting question is which side was wrong; the reasoning is above, and the short version is
that the drill authenticates as a person, so the gate applies to it correctly. If you disagree —
i.e. if the drill should be a machine path — the fix would belong in the harness anyway, since the
gate keys off the session type rather than the endpoint.
Model: Claude Fable 5. Harness: Claude Code.