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

raystack / frontier / 34089620008
50%
main: 50%

Build:
Build:
LAST BUILD BRANCH: fix-add-auth-button-tooltip
DEFAULT BRANCH: main
Ran 07 Sep 2026 06:14AM 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

07 Sep 2026 05:25AM UTC coverage: 50.011% (+0.3%) from 49.735%
34089620008

Pull #1914

github

rohanchkrabrty
refactor(consent): keep the transaction out of the service layer

The consent record still lands with the user row or not at all, but no
service signature names a database transaction any more. core/user,
core/consent and core/authenticate no longer import sqlx.

user.Repository gains CreateWithConsent in place of CreateWithTx, and the
Postgres implementation opens the transaction itself, writing the user row
and then the consent record through the repository that already owns that
table. Both user create paths still share buildUserInsertQuery, so they
cannot drift.

consent.Service keeps its config, its documents, its resolve rules and its
audit record. What changed is that Grant, which wrote, becomes PrepareGrant,
which builds and validates the record and performs no I/O. Its Repository
interface had no other caller and is gone, and with it the last *sqlx.Tx in
core. The identity is no longer required by validateGrant: the user id is
generated by the insert, and the writer stamps it from the row it just
wrote, with NOT NULL and a foreign key behind it.

This is deliberately scoped to signup rather than general: the codebase has
no pattern for a transaction spanning two domains, the read-only aggregates
are not one, and organization.AdminCreate shows the current answer is to
sequence the writes and accept partial failure. A general pattern needs its
own research and RFC. Until then the composite write lives with the user
domain, which is where user creation has always lived, and the comments say
so at each site.

The rollback is still proved against a real database, now through
CreateWithConsent rather than a hand-assembled transaction.

See docs/rfcs/0002-explicit-consent-at-signup.md, Enforcement and Storage.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Pull Request #1914: feat(consent): record consent in the same transaction as the user

219 of 253 new or added lines in 7 files covered. (86.56%)

206 existing lines in 2 files now uncovered.

20507 of 41005 relevant lines covered (50.01%)

15.94 hits per line

Uncovered Changes

Lines Coverage ∆ File
19
68.39
0.04% internal/store/postgres/user_repository.go
6
85.0
internal/store/postgres/user_consent_repository.go
5
0.0
0.0% cmd/serve.go
2
50.15
3.01% core/authenticate/service.go
2
94.59
internal/store/postgres/user_consent.go

Coverage Regressions

Lines Coverage ∆ File
107
50.15
3.01% core/authenticate/service.go
99
68.39
0.04% internal/store/postgres/user_repository.go
Jobs
ID Job ID Ran Files Coverage
1 34089620008.1 07 Sep 2026 06:14AM UTC 310
50.01
GitHub Action Run
Source Files on build 34089620008
  • 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 (#33670678790)
  • 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