fix(config): let TMI_OAUTH_CALLBACK_URL outrank the database row

[ericfitz]

Symptom

GET https://api.tmi.dev/oauth2/providers advertised localhost for every provider:

{"id":"google","redirect_uri":"http://localhost:8080/oauth2/callback"}
{"id":"github","redirect_uri":"http://localhost:8080/oauth2/callback"}
{"id":"microsoft","redirect_uri":"http://localhost:8080/oauth2/callback"}

OAuth sign-in cannot complete — Google rejects the redirect_uri mismatch.

The deployment's env var was correct the whole time: the tmi-oauth-providers Secret has TMI_OAUTH_CALLBACK_URL=https://api.tmi.dev/oauth2/callback, and the pod started 4 days after the Secret was last patched, so it definitely had that value. A stale-pod-env explanation is ruled out.

Root cause

auth.oauth_callback_url was the one singleton setting that hardcoded Source: "config" rather than routing through settingSource() — the other 130 all do it correctly. Compare:

setting	registration
server.base_url	Source: settingSource("TMI_SERVER_BASE_URL"), EnvVar: … ✅
auth.oauth_callback_url	Source: "config", no EnvVar ❌

Source feeds Explicit, and SettingsService.getConfigSetting discards any operational setting that is not Explicit (#415). So GetString("auth.oauth_callback_url") always fell through to the database no matter what the operator set. The database held the localhost struct default, and since Handlers.oauthCallbackURL returns the runtime value whenever it's non-empty, that stale row won and the correct env-backed h.config.OAuth.CallbackURL was never reached.

The chain, all confirmed by reading code and live state:

oauthCallbackURL → GetOAuthCallbackURL → GetString("auth.oauth_callback_url")
  → getConfigSetting: found, but !Explicit → not-found
  → DB row: "http://localhost:8080/oauth2/callback"   ← wins
  → (correct env value never consulted)

Fix

Route Source through settingSource("TMI_OAUTH_CALLBACK_URL") and record EnvVar, matching every other env-backed key.

One deliberate subtlety

Only TMI_OAUTH_CALLBACK_URL is named. auth/config.go also honors a legacy OAUTH_CALLBACK_URL, and my first attempt counted both — that was wrong and would have been a worse regression. This package's OAuthConfig.CallbackURL struct tag binds only TMI_OAUTH_CALLBACK_URL, so a legacy-only operator would get Value = localhost default with Source = "environment" → the default becomes Explicit and outranks a correct DB row. A fallback inverted into an override. A test pins this, and settingSource's doc comment now states the constraint.

Tests

Three cases, all verified failing before the fix:

• env var set → Source: "environment", Explicit: true, EnvVar recorded
• env var unset → stays non-Explicit so the DB remains reachable (this is an admin-only, hot-reloadable operational key)
• unbound legacy name set → must not mark the default Explicit

make lint 0 issues · make test-unit 2447 passed / 0 failed

Deploying this is what restores AWS sign-in

Note the ordering problem: the broken callback blocks interactive OAuth login, which blocks the admin API, which is the only way to hot-fix the DB row (service-account tokens are denied on /admin/* per #399). So the DB-row route is not reachable while the bug is live — shipping this fix is the practical path.

config-reference.md is unchanged: auth.oauth_callback_url sits in the Operational table, which has no Env var column.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WnrVyySuyJFqcMxB8q3pNc