Closed paulswartz closed 8 months ago
I wouldn't classify this as a bug since this is behaving as intended.
The idea was to handle issues with the normal supervision tree. It also is quite normal to handle this that way for workers that reference external services.
I would however be open to a retry strategy for the user to specify some behavior on how this should be dealt with.
For this db_connection
s backoff options come to mind:
* `:backoff_min` - The minimum backoff interval (default: `1_000`)
* `:backoff_max` - The maximum backoff interval (default: `30_000`)
* `:backoff_type` - The backoff strategy, `:stop` for no backoff and
to stop, `:exp` for exponential, `:rand` for random and `:rand_exp` for
random exponential (default: `:rand_exp`)
Closed in favor of PR #337
oidcc version
3.1.0
Erlang version
unsure
Elixir version
unsure
Summary
Migrated from https://gitlab.com/paulswartz/ueberauth_oidcc/-/issues/7:
We have an up and coming Open ID connect provider, that goes into maintenance for some hours multiple times per year.
We have run into an issue where a downtime on the end of the Open ID connect provider caused a downtime to our service.
journalctl
log:Current behavior
When the issuer is offline,
oidcc_provider_configuration_worker
crashes with anhttp_error
.How to reproduce
Expected behavior
oidcc_provider_configuration_worker
does not crash. My initial thought would be that the various functions returnprovider_not_ready
, but that doesn't look like it's part of the spec. Maybe the functions themselves still crash, but the worker itself does not?