PR #67064: fix(auth-profiles): make post-success bookkeeping saves non-fatal

• Repository: openclaw/openclaw
• Author: ademczuk
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/67064

Description (problem / solution / changelog)

Summary

Fixes #62099. On Windows, concurrent config hot-reload can leave auth-profiles.json with a ReadOnly attribute. The atomic write in saveAuthProfileStore then throws EPERM, and because markAuthProfileGood / markAuthProfileUsed / markAuthProfileFailure run as post-completion bookkeeping, that throw used to cascade into the LLM request that had already succeeded. Fallback triggers, hits the same read-only file, fails the same way. The gateway becomes unresponsive; restarts don't help because the file attribute persists.

The fix wraps the body of each mark* function in try/catch, logging the persistence failure and continuing. Caller-visible behavior is unchanged on the happy path.

What this does NOT change

saveAuthProfileStore itself still throws on failure. OAuth token refresh (in oauth.ts) depends on that behavior, since a silent token-save failure would be a security concern. Only the three mark* functions that run after a successful provider call now tolerate save errors.

Scope

• src/agents/auth-profiles/profiles.ts - wrap markAuthProfileGood body in try/catch, log warn
• src/agents/auth-profiles/usage.ts - wrap markAuthProfileUsed and markAuthProfileFailure bodies in try/catch, log warn
• src/agents/auth-profiles/usage.persist-nonfatal.test.ts - new regression tests, one per mark function, simulating EPERM from both the lock-guarded and direct save paths

markAuthProfileCooldown delegates to markAuthProfileFailure so it's covered transitively.

Before

Error: EPERM: operation not permitted, copyfile
  'auth-profiles.json.<uuid>.tmp' -> 'auth-profiles.json'
    at Object.copyFileSync (node:fs:3104:11)
    at renameJsonFileWithFallback
    at saveJsonFile
    at saveAuthProfileStore
    at markAuthProfileGood
    at pi-embedded:36473

The LLM response arrived, then the save threw, then every fallback hit the same file, then the gateway ran out of models. User hits attrib -R on the file and restarts to recover.

After

The save throws, the catch runs, the warning lands in the subsystem log, the mark function returns void, the LLM request completes normally. lastGood / usage stats stay slightly stale until the next successful save, which is the right tradeoff for a bookkeeping write.

Testing

• New tests in usage.persist-nonfatal.test.ts pass (3/3). Mocks both updateAuthProfileStoreWithLock and saveAuthProfileStore to throw EPERM, asserts the mark* functions resolve without throwing.
• Existing usage.test.ts (39 tests) and auth-profiles.markauthprofilefailure.test.ts (9 tests) still pass. Also verified auth-profiles.runtime-snapshot-save.test.ts (1 test).
• Two pre-existing test failures in state-observation.test.ts and oauth.fallback-to-main-agent.test.ts already fail on main, unrelated to this change.
• oxlint --type-aware clean on modified files.
• tsgo --noEmit clean (exit 0).
• oxfmt --check clean.

Risk

Low. Behavioral change is scoped to the error path of a bookkeeping function. Callers that previously got an unhandled rejection on EPERM now get a resolved promise, which is the intended outcome. Profile state in memory stays authoritative; disk just gets slightly stale until the next successful write.

AI disclosure

This change was drafted with Claude Code acting as coding assistant. The issue was picked from the triaged backlog, the root-cause analysis and implementation plan were produced interactively, and tests were written against the exact stack trace in the issue report. Human review of the patch and regression tests before submission.

Understanding confirmation

Yes, I've read CONTRIBUTING.md and VISION.md. This is a single-concern bug fix with no dependency updates, no schema changes, and no new public APIs. The affected module is src/agents/auth-profiles/. No Carbon changes, no @ts-nocheck, no lint suppression.

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/agents/auth-profiles/profiles.ts (modified, +32/-20)
• src/agents/auth-profiles/usage.persist-nonfatal.test.ts (added, +87/-0)
• src/agents/auth-profiles/usage.ts (modified, +113/-91)

PR #67077: fix(auth-profiles): make post-success bookkeeping saves non-fatal

• Repository: openclaw/openclaw
• Author: ademczuk
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/67077

Description (problem / solution / changelog)

Summary

Fixes #62099. On Windows, concurrent config hot-reload can leave auth-profiles.json with a ReadOnly attribute. The atomic write in saveAuthProfileStore then throws EPERM, and because markAuthProfileGood / markAuthProfileUsed / markAuthProfileFailure run as post-completion bookkeeping, that throw used to cascade into the LLM request that had already succeeded. Fallback triggers, hits the same read-only file, fails the same way. The gateway becomes unresponsive; restarts don't help because the file attribute persists.

The fix wraps the body of each mark* function in try/catch, logging the persistence failure and continuing. Caller-visible behavior is unchanged on the happy path.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Auth / tokens

Linked Issue/PR

• Closes #62099

User-visible / Behavior Changes

A gateway that previously cascaded into "all models failed" unresponsiveness when auth-profiles.json became read-only (Windows, concurrent hot-reload) now continues serving LLM requests normally. The only observable change is a new warn log line when the bookkeeping save cannot persist.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

saveAuthProfileStore itself still throws on failure. OAuth token refresh (in oauth.ts) depends on that behavior, since a silent token-save failure would be a security concern. Only the three mark* functions that run after a successful provider call now tolerate save errors. markAuthProfileCooldown delegates to markAuthProfileFailure so it's covered transitively.

Repro + Verification

Environment

• OS: Windows 11 (reproduced from user report); Linux in CI
• Runtime/container: Node 22
• Model/provider: Anthropic primary, Ollama fallback (per user report)
• Integration/channel (if any): None
• Relevant config (redacted): auth-profiles.json with Windows ReadOnly attribute set

Steps

1. Gateway runs on Windows with primary + fallback providers configured
2. User adds a new model to openclaw.json while the gateway is hot-reloading
3. Windows sets ReadOnly on auth-profiles.json during the concurrent rename
4. Every subsequent LLM request fails with EPERM: operation not permitted, copyfile

Expected

LLM requests complete. Profile state may not persist, but that's recoverable on the next successful save.

Actual

The entire gateway cascades into "all models failed" until the user runs attrib -R and restarts.

Evidence

• Failing test/log before + passing after - see new usage.persist-nonfatal.test.ts
• Stack trace from the issue:

Error: EPERM: operation not permitted, copyfile
  'auth-profiles.json.<uuid>.tmp' -> 'auth-profiles.json'
    at Object.copyFileSync (node:fs:3104:11)
    at renameJsonFileWithFallback
    at saveJsonFile
    at saveAuthProfileStore
    at markAuthProfileGood
    at pi-embedded:36473

Human Verification (required)

Verified scenarios:

• Ran new regression tests (usage.persist-nonfatal.test.ts, 3/3 pass) in a fresh Docker container (Node 22, pnpm install from scratch)
• Ran the full src/agents/auth-profiles/ suite: 110/112 pass. The 2 failures (session-override.test.ts and oauth.openai-codex-refresh-fallback.test.ts variously) also fail on clean main with identical counts, so they're pre-existing flakiness unrelated to this change
• pnpm tsgo --noEmit clean (exit 0)
• oxlint --type-aware on modified files: 0 warnings, 0 errors
• oxfmt --check on modified files: clean

Edge cases checked:

• Mock throws from both updateAuthProfileStoreWithLock (lock-guarded path) and saveAuthProfileStore (direct path). Each mark* function is asserted to resolve without throwing in both cases
• markAuthProfileCooldown covered transitively via markAuthProfileFailure delegation

What I did not verify:

• Live Windows reproduction of the ReadOnly race. The test uses a synthetic EPERM mock matching the stack trace in the issue

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Failure Recovery (if this breaks)

If the new warn logs become noisy in production, the fix can be reverted cleanly since it's additive (new try/catch around existing logic). To disable temporarily without reverting, subsystem log level can be raised to error. Files to restore: src/agents/auth-profiles/profiles.ts, src/agents/auth-profiles/usage.ts. Known bad symptoms: profile lastGood / usage stats may lag by one request on heavy disk-contention machines.

Risks and Mitigations

• Risk: Silencing all throws in mark* could mask a genuine bug in the usage-stats computation

  • Mitigation: The try/catch is narrow (function body only), computation is pure (no IO), and failures land in log.warn with the full error message so ops can still see them

• Risk: saveAuthProfileStore being called from other paths (OAuth token refresh, store inheritance) might also hit EPERM and still throw

  • Mitigation: Intentional. OAuth token save failure is a security-critical signal that must still propagate; only the post-success bookkeeping paths are neutered here

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/agents/auth-profiles/profiles.ts (modified, +38/-20)
• src/agents/auth-profiles/usage.persist-nonfatal.test.ts (added, +89/-0)
• src/agents/auth-profiles/usage.ts (modified, +142/-109)