fix(agent-core-v2): keep running sessions' models alive across concurrent provider refreshes - #3512
Conversation
🦋 Changeset detectedLatest commit: 68159b7 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2985f9bb77
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| providers: pickDefined(next.providers, [KIMI_CODE_PROVIDER_NAME]), | ||
| models: pickDefined(next.models, refreshedAliasKeys), |
There was a problem hiding this comment.
Preserve full sections for atomic TUI refreshes
When a refresh runs through the v2 TUI harness, apps/kimi-code/src/tui/controllers/auth-flow.ts passes this patch to replaceConfigSections, which replaces each supplied top-level section rather than merging its entries. Because these lines now send only the refreshed provider and aliases, the first changed provider replaces [providers] and [models] with those sparse records, deleting every unrelated provider and model alias from the user's config. The atomic host must rebase sparse entries onto the latest complete sections, or this caller must continue receiving complete records.
Useful? React with 👍 / 👎.
| for (const id of this.cache.keys()) { | ||
| if (this.models.get(id) !== undefined) this.cache.delete(id); |
There was a problem hiding this comment.
Scope retained catalog entries to active sessions
IModelCatalog is registered at app scope, so retaining every deleted cached alias is not limited to the running session that needs it. Once any session has resolved an alias, deleting that alias from config leaves this cache entry available indefinitely; a later session in the same daemon can explicitly bind the deleted alias and reuse its stale provider endpoint and authentication material instead of receiving MODEL_NOT_FOUND. Retention needs to be tied to active session usage rather than all previously cached entries.
Useful? React with 👍 / 👎.
…rent provider refreshes
2985f9b to
68159b7
Compare
Related Issue
No linked issue — reported directly: when multiple Kimi Code processes start at the same time, each refreshes provider model lists on startup, and a refresh in one process can make a model in use by another process fail with
Model "<provider>/<model>" is not configured in config.toml.Problem
Every process refreshes provider model lists against the shared
config.toml(startup refresh, interval refresh, manual refresh). The refresh writes were whole-section replacements of[models]/[providers]computed from a snapshot taken before the network fetch:Because every process watches
config.tomllive, the deletion propagated immediately: the running session's next request re-resolved the model against the updated config and failed withModel "..." is not configured in config.toml., killing the session mid-turn.What changed
[models]/[providers]tables, and the write rebases onto the latest on-disk config, so concurrent writes from other processes survive.Checklist
/approve).gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.