Disabling openid provider on startup is confusing when provider is still working

[decentral1se]

• Gitea version (or commit ref): 1.13.4
• Git version: 2.20.1
• Operating system: GNU/Linux Debian buster
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
• Log gist: N/A

Description

While upgrading to 1.13.4, my keycloak openid provider was temporarily down. I had this openid provider enabled and working before the upgrade. After upgrading, the openid login button was gone. Looking back at the changelog, it seems in 1.13.3, a change was implemented to disable openid providers that were not reachable and avoid failing startup. That is a good change imho but disabling them leads to the case where your openid login is gone away but it should not be. Is it possible to not fail and not disable them? A retry window in place before disabling? I am not sure what is best but having the provider disabled is not ideal.

Refs: #14802

[ghmer]

Supporting that, at least make it configurable whether it should automatically be disabled. Or, even better: Retry, until the authentication source is up again. Right now, it is just confusing users.

[zeripath]

If we don't disable it the system fatals.

What you're basically asking for is a temporarily disabled status?

[zeripath]

I mean you can always go into system admin and reenable it.

[ghmer]

This is not a binary issue, there are ways between "I must disable the authentication source" and "I must use log.Fatal". In example, why not put the authentication source in a retry list and have a thread periodically check whether it is available again?
Sure I can always admin into the system, but I'd rather see one user having a login issue but the system will "heal itself" (because I know the authentication source will be up in probably another minute) than getting several tickets overnight until I wake up the next morning and enable that thing again.

[ctII]

Self-healing providers could have a blip in their uptime at the same time as Gitea starts due to timing differences in startup, especially when deployed on the same Kubernetes cluster, but that shouldn't prevent providers from being used later if they are available

Could a new task in modules/cron that attempts to initialize disabled providers in models/oauth2 from the database on a periodic basis solve this?