[iscekic]

Problem

The platform routing table published only when no platform registry row was pending or running. A pair being measured is not served yet, so that gate made publication wait on the slowest measurement in the queue instead of on table readiness.

The registry row is shared between the two queues: a user-purpose run claims the same row the platform queue admitted. One such run held a new DeepSeek snapshot pair in running from the moment it started, and every PUT /admin/config in that window logged routing_table_publish_skipped_queue_unsettled, leaving the live table on the previous build.

Invariant

Publish when every pair the published table serves either still carries over, or was deliberately removed.

The serving set cannot express that: servingSubscriptionSnapshot already restricts servingPairs to rows that are ready under the current engine, so it is empty after a bump and fills one pair at a time. The gate therefore diffs the published table:

• A live pair with a ready current-engine row carries over.
• A live pair that is still a target, and whose row is missing, pending or running, blocks. That is a re-measurement in flight or an engine bump, and publishing would drop a pair the table serves.
• A live pair whose own re-measurement settled failed drops out, as it did when the gate counted only pending and running rows.
• A pair that is a target but not yet served never blocks. This is the defect being fixed: a new pair, or a pair claimed by the user queue, used to hold the whole table back.

Change

• publishPlatformRoutingTable reads the published table once, before the build, and reuses it for the identical-version check.
• It blocks on routing_table_publish_skipped_serving_pair_unready with the model, variant and current status.
• Comments in db.ts that described a reaped claim as holding the queue unsettled now state the real consequence: the pair is neither served nor re-measured, so the table never gains it.

Verification

• pnpm vitest run in services/auto-routing-benchmark: 909 tests pass.
• pnpm typecheck, pnpm lint: clean.
• Coverage: a new pair still measuring does not block; a live pair still re-measuring blocks; a live pair with no row under this engine blocks; a live pair that settled failed drops out; the engine-bump sequence publishes nothing until every live pair is ready again.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The new gate now diffs the published table instead of the already-narrowed serving set, so a live pair that is still a target and has no ready current-engine row blocks publication while a newly admitted pair no longer does; both previously reported findings are addressed at 0cdc17e.

Assumptions: [INFERENCE] Verified servingSubscriptionSnapshot (subscriptions.ts:369-391) still narrows servingPairs to ready rows, so desired alone cannot expose a disappearing live pair, and that the new livePairs diff is the correct substitute. The gate fails open if getLatestRoutingTable rejects or the persisted table fails schema validation, since .catch(() => null) maps both to "no live table"; I did not treat this as a finding because a D1 write failure would normally accompany a read failure and the same catch pattern pre-existed for the version check. No runtime tests were executed in this read-only review.

Files Reviewed (2 files)

• services/auto-routing-benchmark/src/run.ts - 0 issues
• services/auto-routing-benchmark/src/profile-runs.test.ts - 0 issues

Previous Review Summaries (2 snapshots, latest commit f7e6ac2)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit f7e6ac2)

Status: 1 Issue Found | Recommendation: Address before merge

Executive Summary

The new failed exemption does not fix the core gap: the publish gate is still computed from servingPairs after servingSubscriptionSnapshot has already narrowed it to ready rows, so an engine-identity or repetitions change can still publish a single-model table.

Assumptions: [INFERENCE] Verified servingSubscriptionSnapshot (subscriptions.ts:373-381) replaces servingPairs with the ready subset when no serving pair left the target set and retains the old pairs only when a served pair is being replaced; no runtime tests were executed in this read-only review.

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
services/auto-routing-benchmark/src/run.ts	538	desired is derived from the already-narrowed servingPairs, so in the normal path every desired pair is in readyPairs and blocking is unreachable; after an engine-identity/repetitions change, publication still proceeds as soon as the first new-engine pair is ready, publishing a thin single-model table. The new tests only exercise this branch because servingSubscriptionSnapshot is mocked.

Files Reviewed (3 files)

• services/auto-routing-benchmark/src/run.ts - 1 issue
• services/auto-routing-benchmark/src/profile-runs.test.ts - 0 issues
• services/auto-routing-benchmark/src/run-process-job.test.ts - 0 issues

Previous review (commit 6804a1e)

Status: 1 Issue Found | Recommendation: Address before merge

Executive Summary

The replacement publish gate compares against serving pairs that servingSubscriptionSnapshot has already narrowed to ready rows, so it cannot detect an unready served pair, while an engine-identity or repetitions change still publishes a one-model table once the first new-engine pair finishes.

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
services/auto-routing-benchmark/src/run.ts	525	desired comes from servingPairs, which is recomputed to the ready subset, so unreadyServingPair is effectively unreachable; conversely, after an engine-identity/repetitions change servingPairs clears and then collapses to the first ready pair, publishing a thin (single-model) table before the rest are measured. The docstring's claim that previous serving pairs are retained after an engine bump does not hold for the code path that clears them.

Files Reviewed (3 files)

• services/auto-routing-benchmark/src/run.ts - 1 issue
• services/auto-routing-benchmark/src/db.ts - 0 issues
• services/auto-routing-benchmark/src/profile-runs.test.ts - 0 issues

Fix these issues in Kilo Cloud: Fix these issues in Kilo Cloud

---

_{Reviewed by deepseek-flash-latest · Input: 60.2K · Output: 14.9K · Cached: 765.1K}

_{Review guidance: REVIEW.md from base branch main}