root: implement liveness endpoint in a middleware - #25598
Draft
severin wants to merge 1 commit into
Draft
Conversation
As per Kubernetes best practices liveness probes should not hit any dependencies (like databases). Currently the liveness probe implementation triggers multiple database queries (for tenant and brand; from middlewares). This change implements the liveness endpoint in a middleware that runs before anything else, therefore any side-effects from other middlewares are skipped. Note: This means that liveness endpoint calls no longer are treated as "normal" Django requests and won't be reported in e.g. Prometheus metrics.
2 tasks
✅ Deploy Preview for authentik-storybook 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 @@
## main #25598 +/- ##
==========================================
- Coverage 91.67% 91.65% -0.02%
==========================================
Files 1151 1152 +1
Lines 73416 73508 +92
Branches 4054 4054
==========================================
+ Hits 67302 67373 +71
- Misses 6072 6093 +21
Partials 42 42
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. |
BeryJu
reviewed
Aug 31, 2026
| urlpatterns = [ | ||
| path(CONFIG.get("web.path", "/")[1:], include(_urlpatterns)), | ||
| path("-/metrics/", MetricsView.as_view(), name="metrics"), | ||
| path("-/health/live/", LiveView.as_view(), name="health-live"), |
Member
There was a problem hiding this comment.
I'd prefer keeping this as a placeholder view (doesn't have to have any logic), just so we can be consistent with using reverse for the path
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.
This is a suggestion on top of #25597. I personally find it the better approach because there's no easy way for regressions (i.e. new middlewares that add database queries and would have to be remembered to skip). Also, it's more efficient (and therefore probably more performant, though I'm not sure how quantifiable the impact is) since almost the whole Django request processing can be skipped.
As per Kubernetes best practices liveness probes should not hit any dependencies (like databases):
Currently the liveness probe implementation triggers a few database queries (for tenant and brand; from middlewares).
This PR proposes the following way to address this: It implements the liveness endpoint in a middleware that runs before anything else, therefore any side-effects from other middlewares are skipped.
Note: This means that liveness endpoint calls no longer are treated as "normal" Django requests and won't be reported in e.g. Prometheus metrics. I added a mention of this in the docs but it should probably also be called out in the release notes.
Since this is quite a big change to how things work currently I'm also proposing a less intrusive (but more manual) approach in #25597
Details
What does this PR change?
It implements the liveness endpoint in a middleware that runs before anything else instead of a Django view. Therefore any side-effects from other middlewares are skipped.
Why is this change needed?
To remove any (accidental) external dependencies for the liveness probe endpoint
How was this tested?
By adding a unit test and manually verifying that the endpoint returns the desired status.
Disclaimer
I used an AI agent (opencode with Claude Opus and Gemini Flash) to help with the implementation. But all the changes were reviewed and tested manually.
Checklist
make all)make docs)