Self-hosted Appwrite 1.9.6: OIDC provider configuration is periodically wiped

Hi, I’m experiencing a recurring issue with OIDC authentication on a self-hosted Appwrite 1.9.6 instance.

After configuring and enabling the OIDC provider, everything works correctly for some time. Later, the provider is not only automatically disabled—the entire OIDC configuration is deleted, including the Client ID, Client Secret, issuer URL, and other settings. I then have to configure the provider again from scratch.

Additional information:

Appwrite version: 1.9.6, self-hosted with Docker

The affected project does not contain any Functions or scheduled cron jobs

Other projects on the same Appwrite instance do have Functions with cron schedules

Nobody is manually changing the OIDC settings

The issue happens repeatedly after some time

This is an actual persisted configuration change in the Console, not only a project_provider_disabled error during login

The full OIDC configuration disappears, rather than just the provider being toggled off

I found similar reports where a scheduled Function worker could overwrite OAuth settings using a stale project configuration. However, there are no Functions in the affected project, and the issue still occurs on Appwrite 1.9.6, which should already contain the sparse OAuth provider update/cache fixes.

Can a Function running in a different project somehow cause this, or is there another worker/cache path in 1.9.6 that can overwrite the OIDC configuration? What logs or database changes should I monitor to identify which process is updating the project?

that's a strange bug indeed, and doesn't not seems to be wide spread.

Regarding the settings iirc, when you disable an Oauth provider, it's settings are removed as well, so that might be why it's removed.

The real question is why the OIDC Oauth disable itself. Could you check :

• The appwrite container logs ? - in the time where it disabled, is there any error or request regarding oauth
• With the devtools open, try to enable it, and check the network activity to see if it saved, then reload the page to check if it worked
• other possibility, the Disable all in the auth method was pressed, which might disable Oauth config as well

Thanks. We are currently waiting for the issue to happen again so that we can collect the Appwrite container logs around the exact time the provider gets disabled.

Regarding the other two points:

• We can confirm that the configuration is saved successfully. OIDC login works normally after enabling and configuring the provider, and continues working until the configuration eventually disappears.
• We don’t believe anyone is pressing Disable all. The issue repeatedly affects this specific project without anyone intentionally changing its authentication settings. Unless we have some very dedicated office gremlins, a manual action seems unlikely. 🙂

Once it happens again, we’ll share the exact timestamp and any relevant requests or errors from the Appwrite container logs. Is there a specific log pattern, endpoint, or container besides the main appwrite container that we should monitor?

since i didn't saw the errors for OAuth i can't really tell the pattern for that specific case, but you could for example try to grep keywords like OAuth or OIDC to avoid mass outputs.
Also regarding the containers, everything regarding OAuth is handled by the appwrite container, so shouldn't be anything in the others containers.

Other thing, if your maybe using an appwrite.config.json or appwrite.json to deploy things, make sure the OAuth is there too, as it can override thoses settings. (if you use it to just push functions/sites then that shouldn't be the cause)

Update: it disabled itself again, about 13 hours after I re-enabled it. The audit shows my re-enable at 07:11 UTC, it was still working at 17:00 UTC, and the project row was written at 20:45:33 UTC — the cached copy from that same moment already had oAuthProviders: false.
I think I found it, and it's the project document cache rather than the database.
The MariaDB row was fine the whole time. I read oAuthProviders straight from the DB, bypassing the cache, and it decrypted correctly with the current _APP_OPENSSL_KEY_V1 with all the settings still in it. But the copy cached in Redis had oAuthProviders: false — which is why the console showed an empty, disabled provider and createOAuth2Session returned 412.
Deleting that one cache key fixed it instantly. Settings intact, nothing saved:

docker compose exec -T redis redis-cli DEL
"default-cache-mariadb:_console::collection:projects:"So it's a temporary fix rather than a real one — it will come back. It also explains why there was never anything in the audit log: no write ever happened.
If it's useful I can share the full chain I traced: the encrypt filter returns false when openssl_decrypt fails and nothing checks it; getDocument() then caches that false, so it serves every read until the entry expires (Database::TTL is 24 hours) or some write to the project row purges it; and re-saving the provider in the console converts that false to an empty array at Base.php:391, which is what wiped my second provider's credentials.