-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
core: fix transactional app creation failing with read replicas (2025.12) #19087
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
8425f7e to
d915d1a
Compare
✅ Deploy Preview for authentik-integrations ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for authentik-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for authentik-integrations ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for authentik-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## version-2025.12 #19087 +/- ##
===================================================
+ Coverage 92.81% 93.31% +0.50%
===================================================
Files 946 946
Lines 52076 52078 +2
===================================================
+ Hits 48334 48597 +263
+ Misses 3742 3481 -261
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
When authentik is configured with PostgreSQL read replicas, the application wizard fails with "Invalid pk - object does not exist" for the provider field. The issue occurs in the blueprint validation flow: 1. Provider is created on the primary database (e.g., PK 159) 2. KeyOf.resolve() returns this PK for the application's provider field 3. ApplicationSerializer.is_valid() validates the provider FK 4. DRF's PrimaryKeyRelatedField queries to verify the PK exists 5. FailoverRouter routes this read to a replica 6. Replica can't see the provider - it's uncommitted (validation runs inside transaction_rollback()) The fix replaces provider and backchannel_providers fields with IntegerField when running in blueprint context. This allows the PK value to pass through without a DB lookup, and using source="provider_id" assigns directly to the FK's _id field. This is safe because: - The provider is created in the same blueprint transaction - The KeyOf reference correctly links them during blueprint apply() - The blueprint importer handles the actual FK assignment
2c3a251 to
d899170
Compare
|
authentik PR Installation instructions Instructions for docker-composeAdd the following block to your AUTHENTIK_IMAGE=ghcr.io/goauthentik/dev-server
AUTHENTIK_TAG=gh-d899170537ed311533c079ad4f1e6ad98a2d9ede
AUTHENTIK_OUTPOSTS__CONTAINER_IMAGE_BASE=ghcr.io/goauthentik/dev-%(type)s:gh-%(build_hash)sAfterwards, run the upgrade commands from the latest release notes. Instructions for KubernetesAdd the following block to your authentik:
outposts:
container_image_base: ghcr.io/goauthentik/dev-%(type)s:gh-%(build_hash)s
global:
image:
repository: ghcr.io/goauthentik/dev-server
tag: gh-d899170537ed311533c079ad4f1e6ad98a2d9edeAfterwards, run the upgrade commands from the latest release notes. |
|
Confirming fix works as expected 🎉 |
THIS IS A FIX FOR #19086 FOR VERSION 2025.12 SPECIFICALLY TO ALLOW ME TO GET A PRE-BUILT IMAGE FOR MY PRODUCTION AUTHENTIK WITH THE SAME CONFIGURATION AS OTHER BUILT IMAGES