feat(consent): record consent in the same transaction as the user - #1914
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 33429107831Coverage increased (+0.3%) to 49.922%Details
Uncovered Changes
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 invariant this establishes: a user row without a consent record is impossible. ResolveAll runs before the transaction opens, so an incomplete payload never starts one; inside it, the user insert and the consent insert both land or neither does. user.Repository and the new user_consents repository each gain a Create that takes a *sqlx.Tx. pkg/db has WithTxn but carries no transaction on the context, so the transaction is threaded through explicitly rather than found on one. Both are additive, and the user repository change is the one place this feature reaches outside its own domain. The consent repository has Create and nothing else, because the table is immutable. consent.Grant writes one record for the documents it is given and has no completeness rule of its own. ResolveAll is what decides a signup covers every configured document, and keeping that out of Grant leaves room for a later re-consent covering a subset without a second write path. getOrCreateUser now has three outcomes for a new user. A complete payload writes both rows in one transaction. An incomplete one returns ErrConsentRequired and writes nothing. An existing user gets no record at all, which is absolute: a record written outside a user creation would carry that moment's timestamp and IP for an agreement made elsewhere, which is worse than no record because it reads like evidence. A nil flow means one of the paths that create a user without one, and those stay exempt because no account holder is present to consent. The completeness check runs at user creation under every intent, not for the error but as the invariant guarding the write. An unset intent is permissive for the login gate but never for consent. With app.consent disabled ResolveAll resolves nothing, and an empty document set means write no record, so nothing changes for a deployment that does not ask for consent. Each signup also writes one audit record, with UserConsentGrantedEvent and ConsentType added to pkg/auditrecord following the entity.verb naming already there. It goes through the repository with the actor filled in, as userpat does for its PAT events: the repository enriches an empty actor from the context, and these endpoints are on the authentication skip list with no actor in it, so the record would otherwise land as the system actor for an act a person performed. It is written after the commit, since the audit repository has no transactional create, so it cannot be atomic with the record it describes. That is why the consent record is the source of truth and this one is a breadcrumb: a failure is logged and the signup stands. The rollback is tested against a real Postgres rather than a mocked transaction, since a mock can only pretend to roll back. See docs/rfcs/0002-explicit-consent-at-signup.md, Enforcement and Storage.
rohanchkrabrty
force-pushed
the
feature/featconsent-record-consent-in-the-same-transaction-as-the
branch
from
August 31, 2026 19:10
481c8eb to
c396eaa
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
2 participants
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
ResolveAllruns before the transaction opens, so an incomplete payload never starts one; inside it, the user insert and the consent insert both land or neither does. Per RFC 0002, Enforcement and Storage.user.RepositorygainsCreateWithTx, which is the one place this feature reaches outside its own domain.pkg/dbhasWithTxnbut carries no transaction on the context, so it is threaded through explicitly. Both create paths share one query builder, so they cannot drift.user.consent_grantedaudit record is written after the commit, through the repository rather than the service, withActorfilled in explicitly — these endpoints are skip-listed, so an empty actor would be enriched to the nil UUID and thesystemactor for an act a person performed. It cannot be atomic with the consent row, which is why that row is the source of truth and a failed audit write is logged and carried past.