You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 30, 2022. It is now read-only.
* Don't create a new engine as part of running the health checks and share a single engine across the application, including for the health checks. Currently we're using the default pool_size and max_overflow.
* Update changelog.
* Fix that health checks are still supposed to run, even if the database is disabled.
* Need to yield instead - 'generator' object has no attribute 'query'
* Don't create a new engine as part of running the health checks and share a single engine across the application, including for the health checks. Currently we're using the default pool_size and max_overflow.
* Update changelog.
* Fix that health checks are still supposed to run, even if the database is disabled.
* Need to yield instead - 'generator' object has no attribute 'query'
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Bug Description
The health check endpoint is creating new engines which are probably creating their own connection pools each time it is called. We should be sharing an engine https://github.com/ethyca/fidesops/blob/main/src/fidesops/ops/api/v1/endpoints/health_endpoints.py#L37
This opens up too many connections against the fidesops database very quickly.
h/t @RobertKeyser and @sanders41 for finding this.
Steps to Reproduce
Bring up the fidesops server and monitor your connections against the fidesops application database.
Expected behavior
A description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: