feat(config): add deprecation mechanism and rename loop retry limit - #2572
Conversation
- agent-core-v2 config: declarative section `deprecations` (deprecated TOML keys are ignored and report a warning diagnostic; the file is never rewritten) and env binding `deprecatedEnv` (old var still resolves as a fallback with a warning), surfaced via the new `IConfigService.onDidChangeDiagnostics` event - loop_control: rename `max_retries_per_step` to `max_attempts_per_step` and `KIMI_LOOP_MAX_RETRIES_PER_STEP` to `KIMI_LOOP_MAX_ATTEMPTS_PER_STEP`; `max_steps_per_run` moves onto the same mechanism (no longer silently mapped) - kap-server: push the global `event.config.warning` WS event to every connection whenever the config warning set changes - TUI: show config diagnostics in warning yellow at startup instead of the dim startup notice - docs: config-files/env-vars (en+zh), regenerated config manifest, and the agent-core-dev config guide
🦋 Changeset detectedLatest commit: 7bc7a3d The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
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: |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9707b682b0
ℹ️ 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".
| export const configWarningEventSchema = z.object({ | ||
| type: z.literal('event.config.warning'), |
There was a problem hiding this comment.
This defines event.config.warning, but the schema is never added to agentEventSchema below. I checked packages/kap-server/src/protocol/ws-control.ts and packages/kap-server/src/protocol/asyncapi.ts: sessionEventMessageSchema and the generated AsyncAPI document are built from eventSchema, which is that union, so schema-based clients or tests will reject the new warning frames even though the broadcaster sends them. Add configWarningEventSchema to agentEventSchema.
Useful? React with 👍 / 👎.
| @@ -0,0 +1,5 @@ | |||
| --- | |||
| "@moonshot-ai/kimi-code": minor | |||
There was a problem hiding this comment.
This changeset is marked minor while its own summary says existing [loop_control] max_retries_per_step and max_steps_per_run values no longer take effect, so users with those keys lose their configured retry/step limits after upgrading. Either keep compatibility/migrate the old values, or treat this as an incompatible user-configuration change and use the required major-bump flow.
AGENTS.md reference: AGENTS.md:L63-L64
Useful? React with 👍 / 👎.
- add v2/validate-config.ts: validate config.toml with the agent-core-v2 ConfigRegistry, reporting registered-section schema failures as errors and unknown top-level keys / deprecated keys and env vars as non-fatal warnings - route `kimi doctor` config validation through the v2 validator when the KIMI_CODE_EXPERIMENTAL_FLAG master switch is on (lazy dynamic import, keeping the v2 module graph off the default path) - let doctor checks surface non-fatal warning messages on OK results
…oonshotAI#2572) * feat(config): add deprecation mechanism and rename loop retry limit - agent-core-v2 config: declarative section `deprecations` (deprecated TOML keys are ignored and report a warning diagnostic; the file is never rewritten) and env binding `deprecatedEnv` (old var still resolves as a fallback with a warning), surfaced via the new `IConfigService.onDidChangeDiagnostics` event - loop_control: rename `max_retries_per_step` to `max_attempts_per_step` and `KIMI_LOOP_MAX_RETRIES_PER_STEP` to `KIMI_LOOP_MAX_ATTEMPTS_PER_STEP`; `max_steps_per_run` moves onto the same mechanism (no longer silently mapped) - kap-server: push the global `event.config.warning` WS event to every connection whenever the config warning set changes - TUI: show config diagnostics in warning yellow at startup instead of the dim startup notice - docs: config-files/env-vars (en+zh), regenerated config manifest, and the agent-core-dev config guide * feat(cli): validate config.toml against v2 section registry in doctor - add v2/validate-config.ts: validate config.toml with the agent-core-v2 ConfigRegistry, reporting registered-section schema failures as errors and unknown top-level keys / deprecated keys and env vars as non-fatal warnings - route `kimi doctor` config validation through the v2 validator when the KIMI_CODE_EXPERIMENTAL_FLAG master switch is on (lazy dynamic import, keeping the v2 module graph off the default path) - let doctor checks surface non-fatal warning messages on OK results * chore: downgrade loop-control changeset to patch
1 participant
Related Issue
No linked issue — the problem is explained below.
Problem
The per-step retry limit
[loop_control] max_retries_per_stepis misnamed: the value is a total-attempt budget (the initial failure already counts as attempt 1), not a retry count. Renaming a shipped config key properly requires a deprecation path the codebase does not have: the only precedent (max_steps_per_run→max_steps_per_turn) is a silent hand-rolledfromTomlmapping with zero user feedback, and there is no way to warn users who still configure an old key or environment variable.What changed
Config deprecation mechanism (agent-core-v2) — renames are now declared once on the section instead of hand-rolled:
RegisterSectionOptions.deprecations: a deprecated TOML key is ignored (its value no longer applies), reports a warning diagnostic on every load/reload, and the user's file is never rewritten — the warning is the migration guide.EnvBinding.deprecatedEnv: a renamed env var still resolves as a fallback (new var first) with a warning; thestripEnvwrite guard covers it too.diagnostics()pipeline, and a newIConfigService.onDidChangeDiagnosticsevent publishes the full warning set whenever it changes (including clearing).The rename itself —
[loop_control] max_retries_per_step→max_attempts_per_stepandKIMI_LOOP_MAX_RETRIES_PER_STEP→KIMI_LOOP_MAX_ATTEMPTS_PER_STEP; the oldermax_steps_per_run→max_steps_per_turnmapping was moved onto the same mechanism (its value now also stops applying, with a warning). The deprecation warning points users at/update-config, and the bundledupdate-configskill (v1 + v2) gained a capability that fixes deprecated keys/vars.Warning surfaces:
event.config.warningWS event, fanned out to every connection whenever the warning set changes (live-only; late joiners pull the diagnostics RPC surface).Docs:
config-files/env-vars(en + zh, deprecated-fields table), regeneratedconfig-manifest.toml(the generator now renders deprecations), and the agent-core-dev config guide.Checklist
gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.