Description
Better support for resilience-oriented setups
Problem
Not all orchestrators or environments support the notion of dependent services to ensure that things like database come up prior to FusionAuth starting up.
The approach to how this is handled varies by community and one competing school of thought to specifying dependencies is to rely on restarts and/or retries.
Unfortunately, when FusionAuth fails to get a lock on a database in silent, maintenance mode, it does not terminate or make any retry attempts.
This means that an environment that wishes to handle resilience through restarts or in-built retry mechanisms (or both!) has no way of guiding FusionAuth to a working state.
Solution
All or some combination of:
- An explicit flag to instruct FusionAuth to retry its database connection for a certain period/interval
- An explicit flag to instruct FusionAuth to terminate when it cannot connect to the database
Optionally, one of these could also be the default when running with FUSIONAUTH_APP_SILENT_MODE set to true.
Alternatives/workarounds
Unfortunately there is no alternative or workaround. In some ways, the premise of resilience is itself a workaround oriented approach.
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.
How to vote
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.