• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

raystack / frontier / 33429107831
50%
main: 49%

Build:
Build:
LAST BUILD BRANCH: feature/featauthenticate-separate-login-from-signup-with-an-explicit
DEFAULT BRANCH: main
Ran 31 Aug 2026 07:15PM UTC
Jobs 1
Files 310
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

31 Aug 2026 06:58PM UTC coverage: 49.922% (+0.3%) from 49.642%
33429107831

Pull #1914

github

rohanchkrabrty
feat(consent): record consent in the same transaction as the user

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 audi... (continued)
Pull Request #1914: feat(consent): record consent in the same transaction as the user

221 of 254 new or added lines in 7 files covered. (87.01%)

20461 of 40986 relevant lines covered (49.92%)

15.94 hits per line

Uncovered Changes

Lines Coverage ∆ File
17
67.87
-0.49% internal/store/postgres/user_repository.go
6
0.0
0.0% cmd/serve.go
6
86.36
internal/store/postgres/user_consent_repository.go
2
50.51
3.62% core/authenticate/service.go
2
94.59
internal/store/postgres/user_consent.go
Jobs
ID Job ID Ran Files Coverage
1 33429107831.1 31 Aug 2026 07:15PM UTC 310
49.92
GitHub Action Run
Source Files on build 33429107831
  • Tree
  • List 310
  • Changed 10
  • Source Changed 0
  • Coverage Changed 10
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Pull Request #1914
  • PR Base - feature/featconsent-add-appconsent-config-the-consent-service-and (#33429107722)
  • Delete
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc