Repository navigation
fix(core): named route windows resolve silently — an unknown or unparseable window name drops the gate/rule with no diagnostic (PR #649) #734
Description
Finding
PR #649 added named route windows (experimental.model_route_windows) referenced by name from schedule whens and target window gates. Every name-resolution failure is silent:
- An unknown window name in a target gate drops the gate — the target becomes always eligible, the opposite of the author's intent (they wrote the gate to restrict it).
- An unknown name in a schedule
whendrops the whole weight rule. - A defined-but-unparseable window (e.g.
start: "25:99"— the schema typesstart/endas plain strings, so this passes config decode) is dropped byconfiguredWindowswithout any diagnostic, which makes every reference to it fail the same silent way.
No diagnostic, log line, or decision-log entry records any of this, so a one-character typo in a window name silently removes a peak-hour eligibility gate and routes traffic onto the target the operator meant to keep off-peak. This is the #238 pattern (a misconfigured pool "disappears with no diagnostic") in the new windows feature.
Evidence
- PR: feat(core): named route windows and target eligibility gates (#639) #649 (merge commit
ae8738e08278eae4edbdbc8554826c5b0090a51a) - Current main
packages/core/src/config/plugin/model-routes.ts:176-186—configuredWindows:const parsed = ModelRouteSchedule.parse(window); if (parsed) windows.set(name, parsed)— unparseable entries vanish with no record. - Current main
packages/core/src/config/plugin/model-routes.ts:190-195—resolveWindow: "An unknown name resolves to undefined, which drops the rule." - Current main
packages/core/src/config/plugin/model-routes.ts:198-206—gateFor: "An unknown name drops the gate, leaving the target always eligible." - Current main
packages/schema/src/config/model-routes.ts:42,161— the drop behaviour is documented in the schema descriptions, but nothing surfaces it at load time or run time.
Verified against current origin/main at review time; deduped against open + closed issues (no issue covers window-name resolution diagnostics; #723 covered gate handling inside nested groups, a different defect, and is fixed).
Why it matters
Eligibility gates are a cost/quota control: a DeepSeek target gated to off-peak that silently becomes always-eligible burns peak pricing/quota with no visible signal. Silent drops were the right call for applying a bad rule (don't apply what you can't read), but the drop itself needs a surface.
Acceptance criteria
- Loading config with a target gate or schedule that names an undefined window produces a discoverable diagnostic (config diagnostics and/or a decision/config log entry) naming the window name and where it was referenced.
- A defined window that fails
ModelRouteSchedule.parselikewise produces a diagnostic naming the window, instead of vanishing fromconfiguredWindows. - Valid named windows, inline windows, and the drop-don't-apply semantics are unchanged; tests in
packages/core/test/model-routes-expand.test.ts(or the config suite) pin the diagnostic for the unknown-name and unparseable-definition cases.
Activity
developing-today commentedon Oct 28, 2026
OPENCODE-152
dezren39 commentedon Oct 28, 2026
🤖 Agent note · filed
11 remaining items
dezren39 commentedon Oct 28, 2026
PR #740 opened from
queue/1992-734-window-diagnostics(head0590bdd7c4): all three named-window drop sites inpackages/core/src/config/plugin/model-routes.tsnow warn, naming the window and the reference site —configuredWindows(defined-but-unparseable),resolveWindow(unknown name in a route/global schedule), andgateFor(unknown name in a route gate). Drop-don't-apply semantics unchanged. Tests inpackages/core/test/model-routes-expand.test.tspin both diagnostic cases.Verified on the laptop worktree (
~/git/fleet/1992-734-window-diagnostics):bun test test/model-routes-expand.test.ts— 21 pass, 0 fail. Task 1992 is parked pending CI on PR #740; the next shift resumes from the PR.agent-note:v1 · lane repo-queue-worker-shift-opencode-b · task 1992
dezren39 commentedon Oct 28, 2026
Lane B resumed queue task 1992 at 18:37Z: PR #740 (head
0590bdd7c4) is MERGEABLE, but at 18:39Z every CI check is still QUEUED since 18:17Z (typecheck, nix-eval, unit/build linux+windows, affected packages; only CodeRabbit completed, neutral) — runner backlog, not a change failure. Task re-parked 30m (resume ~19:09Z): next holder checks CI, merges per standing directive if green (excepting pre-existing #565 permission tests / #652 windows git-pack flake), or fixes on the same branch if red on this change.dezren39 commentedon Oct 28, 2026
CI update from Lane B's later check (19:01Z, after task 1992 was re-parked): PR #740's checks have mostly completed — typecheck, nix-eval, check-duplicates, check-standards, affected packages, add-contributor-label, check-compliance and build (linux) all SUCCESS — but unit (linux) and unit (windows) both FAILURE (build (windows) and e2e still pending at check time). The identical unit-failure pattern appears on PRs #738 and #741, which touch unrelated areas, suggesting a shared/pre-existing failure set rather than this change — the resuming holder should compare the failing test names against that pattern (and the known #565 permission tests / #652 flake) before treating it as red-on-this-change.
Merge pull request #740 from developing-today/queue/1992-734-window-d…
dezren39 commentedon Oct 28, 2026
🤖 Agent note · merged
8e3dc87f9321adb012fe6e3c70494cd3ae0863df; this issue closed by the PR.permission layers leave the focused peer's Enter and navigation alone until activatedandpermission rejection text keeps its draft and regains focus when its scope resumes— tracked as open issue unit: two permission-focus tests fail on linux + windows (pre-existing) #565 ("unit: two permission-focus tests fail on linux + windows (pre-existing)") and unrelated to this change (diff is exactlypackages/core/src/config/plugin/model-routes.ts+packages/core/test/model-routes-expand.test.ts; no other(fail)lines in either unit run, so the new diagnostics tests passed). Merged per the standing merge directive after verifying the change itself is sound.