PR #63844: fix: don't persist fallback model to session when channel override is active

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

Description (problem / solution / changelog)

Summary

When a channel-level model override (channels.modelByChannel) is active, the fallback model was being incorrectly persisted to the session. This fix prevents that.

Closes #63712

Testing

• Relevant tests pass

This PR was developed with AI assistance (Claude). All code has been reviewed and tested. Built with islo.dev

Changed files

• src/auto-reply/reply/agent-runner-execution.test.ts (modified, +63/-0)
• src/auto-reply/reply/agent-runner-execution.ts (modified, +12/-1)
• src/auto-reply/reply/agent-runner.ts (modified, +3/-0)
• src/auto-reply/reply/get-reply-run.ts (modified, +3/-0)
• src/auto-reply/reply/get-reply.ts (modified, +7/-1)

PR #63895: fix: don't persist fallback model to session when channel override is active

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

Description (problem / solution / changelog)

Summary

When a channel-level model override is active and the primary model fails, the fallback model selection was persisted to the session entry (modelOverride/providerOverride). This permanently shadowed the channel override on subsequent turns because channel overrides are gated by !hasSessionModelOverride.

Closes #63712

Changes

• Added hasChannelModelOverride parameter through the reply chain (get-reply.ts → get-reply-run.ts → agent-runner.ts → agent-runner-execution.ts)
• Skip fallback persistence when hasChannelModelOverride is true
• Added regression test verifying fallback doesn't pin to session under channel override

Testing

• New test: does not persist fallback selection to session when channel model override is active

This PR was developed with AI assistance (Claude). Built with islo.dev

Changed files

• src/auto-reply/reply/agent-runner-execution.test.ts (modified, +55/-0)
• src/auto-reply/reply/agent-runner-execution.ts (modified, +12/-1)
• src/auto-reply/reply/agent-runner.ts (modified, +3/-0)
• src/auto-reply/reply/get-reply-run.ts (modified, +3/-0)
• src/auto-reply/reply/get-reply.ts (modified, +7/-1)

PR #64471: fix: prevent fallback persistence from clobbering user /models picks

• Repository: openclaw/openclaw
• Author: hoyyeva
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/64471

Description (problem / solution / changelog)

Summary

• Problem: Selecting a model via /models shows "Model changed to X" but the next message reverts to a previous model.
• Why it matters: /models is the primary way users switch models per-session. When it silently fails, users lose trust in model selection and can get permanently stuck on a fallback model they never chose.
• What changed: (1) Skip fallback persistence when the active modelOverride was set by the user (modelOverrideSource === "user", plus legacy entries with no source field). (2) In the Telegram /models callback, use the fresh runtimeCfg instead of the stale startup cfg snapshot for store path and default-model resolution.
• What did NOT change: No changes to how the fallback chain itself is resolved, no changes to how /models shows the picker, no schema/config changes. Channels other than Telegram are unaffected by the second fix (they don't have inline-button model pickers).

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Gateway / orchestration
• Integrations

Linked Issue/PR

• Closes #63611
• Related #63712, #63900
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: Two independent issues, both leading to the same user-visible symptom.
  1. persistFallbackCandidateSelection in agent-runner-execution.ts unconditionally overwrites modelOverride/providerOverride with the fallback model whenever a fallback succeeds. The session entry already carries modelOverrideSource: "user" | "auto" to distinguish user picks from fallback-set values, but the persistence path never checked it. So one transient failure of a user-selected model permanently pinned the session to the fallback.
  2. The Telegram /models callback handler in bot-handlers.runtime.ts used the outer cfg (a snapshot captured at handler-registration time, closed over by registerTelegramHandlers) for resolveStorePath and resolveDefaultModelForAgent, while the inbound message pipeline always uses fresh config via loadConfig(). After a config reload, the override could be written to the wrong store file, or the selected model could be misidentified as "the default" — which deletes the override instead of saving it.
• Missing detection / guardrail: No regression test exercising "user picks model X via /models → X fails → fallback Y succeeds → next message still targets X." Existing tests covered the fallback persistence path but not the user-override interaction.
• Contributing context: modelOverrideSource was added later in the codebase. session-reset-service.ts already treats modelOverride set with modelOverrideSource === undefined as legacy user state for backward compat — that pattern wasn't applied here.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
• Target tests added:
  • src/auto-reply/reply/agent-runner-execution.test.ts — "does not persist fallback selection when modelOverrideSource is user" + "does not persist fallback selection for legacy user overrides without modelOverrideSource"
  • extensions/telegram/src/bot.test.ts — "persists non-default model override using fresh config, not stale startup snapshot"
• Scenario the tests lock in:
  1. With modelOverrideSource: "user" (and the legacy undefined case), a successful fallback to a different model must NOT mutate modelOverride/providerOverride.
  2. With a Telegram bot started with one default model, after loadConfig returns a different default, the callback must still persist the user's selection correctly.
• Why this is the smallest reliable guardrail: Both bugs are pure state-mutation issues at well-defined seams (the persistence helper and the callback handler). Unit tests against those seams catch the regression without needing a running gateway or live model failures.

User-visible / Behavior Changes

• /models selections now survive transient primary-model failures. When the user-selected model rate-limits and a fallback model serves a single response, the next message attempts the user-selected model again (instead of being permanently routed to the fallback).
• No config changes, no command changes, no UI changes.

Diagram

Before (fallback path):
  user picks X via /models   →  modelOverride = X, source = "user"
  send message               →  X fails  →  fallback Y succeeds
  persist fallback           →  modelOverride = Y, source = "auto"  ← clobbered
  next message               →  uses Y (forever)

After:
  user picks X via /models   →  modelOverride = X, source = "user"
  send message               →  X fails  →  fallback Y succeeds
  persist fallback           →  source === "user"  →  skip
  next message               →  uses X (the user's choice)

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

Human Verification (required)

• Verified scenarios:
  • Full unit test suites for agent-runner-execution, model-selection, model-overrides, and the Telegram bot pass locally (114/114 across the related files, plus the 2 new regression tests).
  • Manually traced the flow from /models callback → session store write → next-message session load → createModelSelectionState → fallback persistence to confirm the override survives.
• Edge cases checked:
  • Legacy session entries with modelOverride set but modelOverrideSource === undefined (backward compat — now covered by an explicit test).
  • Cross-provider user selection (e.g., user picks openai/... while config primary is anthropic/...): resolveAgentModelFallbackCandidates already returns no fallbacks in that case, so this PR has no effect there. The user instead sees the existing FallbackSummaryError with cooldown details, which is the correct UX.
• What I did NOT verify: End-to-end behavior against a live model that actually rate-limits (no live LLM testing in this PR — covered by mocked unit tests against the same seam).

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No — legacy session entries (with modelOverride set but no modelOverrideSource) are explicitly handled.

Risks and Mitigations

• Risk: A user whose selected model is in long cooldown will pay the failed-primary cost on every message (since fallback is no longer persisted), making responses slower until they switch models manually.
  • Mitigation: This is strictly better than the previous behavior (silent permanent override). When the entire fallback chain is exhausted, the existing FallbackSummaryError already surfaces a cooldown message to the user, who can then re-select via /models. No new mitigation added in this PR to keep scope tight.

Changed files

• CHANGELOG.md (modified, +1/-0)
• extensions/telegram/src/bot-handlers.runtime.ts (modified, +9/-4)
• extensions/telegram/src/bot.test.ts (modified, +87/-0)
• src/auto-reply/reply/agent-runner-execution.test.ts (modified, +134/-0)
• src/auto-reply/reply/agent-runner-execution.ts (modified, +20/-0)