fix: log auth profile resolution failures instead of swallowing silently by he-yufeng · Pull Request #41271 · openclaw/openclaw

he-yufeng · 2026-03-09T16:44:38Z

Summary

When resolveApiKeyForProvider iterates through auth profile candidates (line 207-225 in src/agents/model-auth.ts), each failed resolution is silently swallowed by a bare catch {}. If all profiles fail — due to OAuth token refresh errors, keychain access issues, corrupted credential files, or network problems — the user gets a misleading error:

No API key found for provider "openai". Configure auth for this agent...

This suggests they haven't configured auth, when the real issue might be a temporary failure that a retry would fix.

Note the contrast with line 177-185 in the same function: when a specific profile is requested, failures properly propagate. Only the auto-discovery loop swallows errors.

What changed

Added debug-level logging for each failed profile resolution attempt:

auth profile "default" failed for provider "openai": Error: OAuth token refresh failed: ETIMEDOUT

Users can see these with --debug output to diagnose why auth isn't working. This matches the logging pattern already used in auth-profiles/oauth.ts for similar error paths.

Test plan

Auth resolution still works normally (successful profiles return immediately)
When all profiles fail, --debug output shows the specific failure for each candidate
The final "No API key found" error is still thrown when no profiles resolve

greptile-apps · 2026-03-09T16:45:57Z

Greptile Summary

This PR fixes silent error swallowing in the auth-profile candidate loop inside resolveApiKeyForProvider. Previously a bare catch {} discarded all resolution failures, leaving users with a misleading "No API key found" error when the real cause was a transient credential issue. The fix adds a module-level SubsystemLogger and emits a debug-level message for each failed profile attempt, consistent with logging patterns elsewhere in the codebase.

src/agents/model-auth.ts: Adds createSubsystemLogger("model-auth") at module scope and replaces catch {} with catch (err) { log.debug?.(...) } — correctly preserving the original flow (continue iterating, let env/custom-key fallbacks run, throw the "no key" error at the end).
The ?. optional chain on log.debug is unnecessary: debug is always present on SubsystemLogger and all other call sites in the codebase omit the ?..

Confidence Score: 5/5

Safe to merge — the change only adds debug-level logging inside an existing catch block, with no impact on control flow or error propagation.
The change is minimal (one new import, one module-level logger constant, one catch binding + log call) and is purely additive. It does not alter any return values, error propagation, or retry logic. The only finding is a cosmetic/style nit (superfluous ?.).
No files require special attention.

_{Last reviewed commit: cb13e91}

greptile-apps · 2026-03-09T16:46:01Z

@@ -221,7 +224,9 @@ export async function resolveApiKeyForProvider(params: {
          mode: mode === "oauth" ? "oauth" : mode === "token" ? "token" : "api-key",
        };
      }
-    } catch {}
+    } catch (err) {
+      log.debug?.(`auth profile "${candidate}" failed for provider "${provider}": ${String(err)}`);


Unnecessary optional chaining on log.debug

debug is always present on SubsystemLogger — the type definition in src/logging/subsystem.ts declares it as a required (non-optional) method, and every instance created by createSubsystemLogger always assigns it. Using ?. here is therefore superfluous and inconsistent with every other log.debug(...) call in the codebase (e.g. src/memory/manager-sync-ops.ts, src/hooks/bundled/session-memory/handler.ts, etc.).

Suggested change

log.debug?.(`auth profile "${candidate}" failed for provider "${provider}": ${String(err)}`);

log.debug(`auth profile "${candidate}" failed for provider "${provider}": ${String(err)}`);

Prompt To Fix With AI

This is a comment left during a code review. Path: src/agents/model-auth.ts Line: 228 Comment: **Unnecessary optional chaining on `log.debug`** `debug` is always present on `SubsystemLogger` — the type definition in `src/logging/subsystem.ts` declares it as a required (non-optional) method, and every instance created by `createSubsystemLogger` always assigns it. Using `?.` here is therefore superfluous and inconsistent with every other `log.debug(...)` call in the codebase (e.g. `src/memory/manager-sync-ops.ts`, `src/hooks/bundled/session-memory/handler.ts`, etc.). ```suggestion log.debug(`auth profile "${candidate}" failed for provider "${provider}": ${String(err)}`); ``` How can I resolve this? If you propose a fix, please make it concise.

When resolveApiKeyForProvider iterates auth profiles and each one throws (e.g., OAuth token refresh fails, keychain access denied, corrupted credential file), the errors are silently swallowed. If all profiles fail, the user gets a misleading "No API key found" error suggesting they haven't configured auth at all. Add debug-level logging so `--debug` output reveals the real failure reason for each profile candidate. This matches the logging pattern used in auth-profiles/oauth.ts for similar error paths.

altaywtf · 2026-03-10T17:38:56Z

Merged via squash.

Prepared head SHA: 049d1e119a4df88ae00870353a9e7134261fe9dd
Merge commit: c2d9386796635970b373ef83528625528f49cb2f

Thanks @he-yufeng!

@altaywtf