test(e2e): cover intent and consent across every auth strategy - #1916
Draft
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueThanks 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 |
Coverage Report for CI Build 33429109833Coverage remained the same at 50.11%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
rohanchkrabrty
marked this pull request as draft
August 31, 2026 10:36
This was referenced Aug 31, 2026
The cross-cutting matrix for RFC 0002 (docs/rfcs/0002-explicit-consent-at-signup.md), through a real server: the three intents against an address that does and does not have an account, at both enforcement points, one case per strategy, and the complete, incomplete and unknown-id consent sets. This is the coverage no single ticket in the stack owns, because it spans the intent, the consent rules and every strategy at once. Two suites, because app.consent is read at boot and cannot be changed on a running server. The enabled one drives mail OTP through test users, OIDC through mockoidc, and passkey up to the ceremony; the disabled one is the promise the RFC makes to every existing deployment, that nothing changes. The rollback case injects a failing insert on user_consents with a trigger, because nothing in the API can produce one: a bad payload is rejected before the transaction opens, and a well-formed write satisfies every constraint on the table. The suites read users and user_consents directly for the two things the API deliberately does not serve, the absence of a user row and the contents of a consent record. Neither passkey finish method is reachable, for two different reasons, and a skipped case says so rather than leaving the hole invisible. The register method validates the attestation before it reaches the gate, so the gate sits behind a ceremony no test here can perform. The login method runs the gate first, but reaching it needs an account carrying a passkey_credentials blob, which only that same ceremony writes. They are untested at unit level too, since the finish flow unit tests drive mail OTP. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hf1XuPCWcHZ7QY5u4WBB2G
rohanchkrabrty
force-pushed
the
feature/teste2e-cover-intent-and-consent-across-every-auth-strategy
branch
from
August 31, 2026 19:10
cde08a6 to
58c08a5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
app.consentis read at boot and cannot be changed on a running server. The enabled one drives mail OTP through test users, OIDC through mockoidc and passkey up to the ceremony; the disabled one is the promise the RFC makes to every existing deployment, that nothing changes.usersanduser_consentsdirectly, for the two things the API deliberately does not serve: the absence of a user row, and the contents of a consent record.