The ALL_ACCOUNTS_INACTIVE->ALL_TARGETS_SKIPPED fix (58ab721fe) added explanatory comments (+7 lines), pushing the file past its frozen 3457 cap. CI's PR-mode check:file-size caught it; local check-file-size.mjs was not re-run after that specific commit.
Same pre-existing upstream test-drift as 038035f93: t23-t24-fallback-resilience.test.ts's T24 case asserts the pre-dispatch-skip scenario returns ALL_ACCOUNTS_INACTIVE, but production code returns the more precise ALL_TARGETS_SKIPPED when recordedAttempts === 0. Caught by this PR's own fresh CI run after the dirty-mergeable-state fix.
Two combo-routing-engine.test.ts cases assert the pre-dispatch-skip scenario (isModelAvailable always false, zero dispatch attempts) returns ALL_ACCOUNTS_INACTIVE. Production code already distinguishes this case via the recordedAttempts === 0 branch and returns the more precise ALL_TARGETS_SKIPPED -- the tests were never updated when that branch shipped upstream, so they fail on a clean release/v3.8.50 checkout independent of this PR's changes.
typecheck:core is its own blocking CI job (quality.yml), separate from
Docs Gates/Merge integrity. Confirmed pre-existing and unrelated to
any current work by branching this worktree directly from
upstream/release/v3.8.50 with no other merges applied.
- accountSemaphore.ts: isBypassed() already excludes null/<=0
maxConcurrency before ensureGate() is called, but a boolean-
returning helper isn't a type predicate TS can narrow through.
Added a targeted `as number` at the one call site, with a comment
explaining why it's safe.
- combo/comboStructure.ts: two module-scope `const HARD_COMPAT_REASONS`
declarations with different values — a genuine "can't redeclare"
compile error, not a narrowing gap. The first (4-item set including
"output_tokens") had zero usages between its own declaration and the
second; the second (3-item set, matching the CompatFilterOptions doc
comment exactly) is what hasHardCapabilityFailure/
describeCapabilityFilterExhaustion/the third call site all actually
use. Removed the dead first declaration.
- combo/comboStructure.ts + combo/fusionPanel.ts: both accessed
`.prompt`/`.model` on a `ComboModelStep | ComboProviderWildcardStep`
union after only excluding `combo-ref`, but `ComboProviderWildcardStep`
has neither field — a real latent bug (fusionPanel would have pushed
`undefined` into a fusion panel for a wildcard step). Narrowed to
`step.kind === "model"` in comboStructure, and switched to the
already-existing `getComboModelString()` helper in fusionPanel (which
correctly resolves to null for unsupported step kinds, mirroring how
combo-ref is already skipped there). Verified directly via a
standalone script exercising both branches (wildcard vs. model step).
- combo/quotaStrategies.ts: imported `preferAntigravityConnectionsWithStoredProject`
from a module that never existed (`../antigravityProjectPersistence.ts`,
distinct from the real `antigravityProjectPersist.ts`) — the function
itself was referenced nowhere else in the codebase. Wrote the missing
implementation: prefers Antigravity connections with a discovered
`projectId` for reset-aware routing, failing open to the full list
when none have one yet (per the file's own "Exclude... from reset-aware
pool" changelog note, softened to a preference — strict exclusion
would empty the pool entirely for a fleet of freshly-added accounts).
Verified directly via a standalone script.
- compression/engines/ccr/index.ts: `enforceGlobalBudget(owner, bytes)`
was called with only `bytes` at one of its two call sites, missing the
`owner` argument the other call site (and the function's own doc
comment on preferring the calling principal's LRU eviction) already
uses correctly. Added the missing `entry.principalId` argument.
- firecrawlQuotaFetcher.ts: `fetchFirecrawlQuota` was annotated to
return `Promise<QuotaInfo | null>` but every return path constructs a
`FirecrawlQuota` (QuotaInfo extended with remainingCredits/planCredits/
extraCreditsInferred/overPlan) — the type the file already defines and
the type `parseFirecrawlCreditUsage` already correctly returns.
Widened the annotation to match; `FirecrawlQuota extends QuotaInfo` so
this stays compatible with the `QuotaFetcher` contract.
npm run typecheck:core and npm run check:dashboard-typecheck both pass
cleanly. A subset of DB-backed tests in this area also fail, but 100%
attributably to an already-tracked, unrelated migration version
collision (134 -> [ccr_blocks, proxy_logs_egress_ip], see
_tasks/features-v3.8.4/9route/POST-MERGE-AUDIT.md) — confirmed by every
failure's stack trace bottoming out at that exact error, not at
anything touched here.
Two more release/v3.8.50 base-red items, both surfaced while chasing
CI failures on unrelated PRs:
- vi.json was missing 8 keys that #9539 (NewAPI/Sub2API aggregator
balance) added to en.json without a matching i18n:sync-ui run —
pt-BR.json already had all 8, only Vietnamese drifted. Added
translations for the 6 provider-settings strings, the feature-flag
description, and the quota tooltip; verified against
tests/unit/i18n-vi-completeness.test.ts (parity, placeholder
preservation, ICU parse — all 5 assertions pass).
- src/lib/db/migrations/120_interception_rules.sql was pure comments
documenting a no-schema-change key_value namespace, with no
executable SQL statement — the migration runner logged
"FAILED: 120_interception_rules — Query contained no valid SQL
statement" on every fresh DB init. 118_provider_param_filters.sql
(same pattern, two migrations earlier) already ends with a bare
`SELECT 1;` no-op for exactly this reason; 120 was just missing it.
Verified directly against better-sqlite3 that the file now executes
without error.
Unblocks Merge integrity and Docs Gates for every PR against
release/v3.8.50, not just this branch:
- changelog.d/features/9415-newapi-sub2api-aggregator-balance.md had a
non-standard YAML frontmatter header that no other fragment in the
tree uses. check-changelog-integrity.mjs reads a fragment's first
non-blank line to validate it starts with a markdown bullet; the
frontmatter's leading `---` made that check fail regardless of the
actual bullet content further down. Removed the frontmatter and
reformatted the body to match the documented changelog.d/README.md
bullet convention.
- docs/ops/VM_DEPLOYMENT_GUIDE.md documented OMNIROUTE_MAX_POOL_SIZE
and OMNIROUTE_DB_POOL_SIZE as tunable env vars, but neither is read
anywhere in the codebase (confirmed via full-repo grep) — this repo
uses SQLite, which has no connection-pool concept these vars could
plausibly control. check:fabricated-docs --strict correctly flags
fabricated env-var claims; removed the bullet rather than
implementing a feature to match invented documentation.
* fix(api): validate request bodies with Zod in 4 routes — restores the t06 gate
The release-green verdict (#9737) lists check:route-validation:t06 as a HARD
failure and it is STILL red on the current tip: four routes call
request.json() and hand-roll `typeof x === "string"` checks instead of using
Zod, which Hard Rule #7 requires and the gate enforces (it scans source and
has no allowlist).
- src/app/api/plugins/marketplace/install (#9445): InstallBodySchema; the
400 'Missing or invalid name field' response is preserved verbatim.
- src/app/api/services/dario/admin/accounts (#8523): DeleteAccountBodySchema
for the optional { alias } DELETE body; query-param path untouched.
- src/app/api/services/dario/admin/login-start (#8523): LoginStartBodySchema;
trimming now happens in the schema, so the forward body is unchanged.
- src/app/api/services/dario/admin/import-from-omniroute (#8523):
ImportBodySchema for connectionId/alias; invalid shapes fall back to the
same 'connectionId is required' 400 as before.
All four keep their exact status codes and messages — this is a validation
mechanism swap, not a contract change (plugins route suite still 33/33).
Adds tests/unit/route-body-validation-t06.test.ts, which runs the gate's own
rule inside the unit suite so the next such route fails on ITS OWN PR instead
of surfacing weeks later in a base-red sweep. Guard verified by mutation:
renaming .safeParse( in one route makes it fail (1 fail), restored from a
pre-probe copy.
Gates: route-validation:t06, file-size, test-discovery, mutation-test-coverage,
dead-code exit 0; typecheck:core clean; eslint clean.
Refs #9737
* fix(memory): register the sqlite backend on the /api/memory/[id] route — every handler 500'd
GET/PUT/DELETE /api/memory/[id] threw `Primary backend "sqlite" not
registered` and returned 500. #8752 (MemoryBackend provider pattern) wired the
route to `@/lib/memory/manager` directly, but the registry is populated by an
import-time side effect in the module INDEX (src/lib/memory/index.ts:23,
`memoryManager.register(sqliteBackend)`). Importing the bare manager gives an
empty registry.
In production the failure is order-dependent, which is why it went unnoticed:
if /api/memory (which imports the index) is hit first in the same process, the
singleton is already populated and [id] works. Reached first — the common case
for a client that edits a known memory id — every request 500s. The sibling
route is the only other consumer and already imports the index; this was the
lone direct-manager import in src/.
- Fix: import from `@/lib/memory` (index) with a comment stating WHY the
indirection matters, so the next refactor does not simplify it back.
- Guard: tests/integration/memory-route-put.test.ts already covered this and
was failing 2/5 on the base (it only surfaced now because the integration
suite runs on the release-PR CI, not per-PR). Now 5/5.
Also fixes a test-isolation defect in the same run:
tests/integration/combo-matrix/context-relay-codex.test.ts reused one combo
name across both tests, and the control failed with `UNIQUE constraint failed:
combos.name` — resetStorage() unlinks the DB file but the previous
better-sqlite3 handle keeps writing to the same inode. Gave the control its own
combo name and parameterized the request builder; the assertion is unchanged
(it never depended on the name). 2/2.
Integration suite on this tip: 936 tests, 32m19s — under the 40min ceiling the
old verdict reported as exceeded (#9737 item 6), which the migration-135
collision was causing.
Refs #9737
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
isStreamingUpstreamError used a key-presence check (parsed.error != null)
which false-positives on benign values some backends emit on every chunk
({}, '', false, 0). When opencode issues a tool-call turn, the upstream SSE
opens with role-only frames (no recognized content) and a later chunk that
carries real tool_calls content PLUS a benign empty error field. The error
gate runs BEFORE content recognizers, so that single frame short-circuits
to 'error' -> 502 'streaming upstream error'. Same combo via kilocode works
because its wire format never emits the empty error field.
Fix: isSubstantiveError() helper — only treat error as real when it carries
non-empty string, non-empty object, or explicit true. Empty object {}, empty
string '', false, and 0 are benign.
TDD: tests/unit/quality-validation-benign-error.test.ts proves tool_calls
chunk with error:{} or error:'' is valid (was 502), while a real error
{message, code} still correctly fails.
The release-green verdict (#9737) lists check:route-validation:t06 as a HARD
failure and it is STILL red on the current tip: four routes call
request.json() and hand-roll `typeof x === "string"` checks instead of using
Zod, which Hard Rule #7 requires and the gate enforces (it scans source and
has no allowlist).
- src/app/api/plugins/marketplace/install (#9445): InstallBodySchema; the
400 'Missing or invalid name field' response is preserved verbatim.
- src/app/api/services/dario/admin/accounts (#8523): DeleteAccountBodySchema
for the optional { alias } DELETE body; query-param path untouched.
- src/app/api/services/dario/admin/login-start (#8523): LoginStartBodySchema;
trimming now happens in the schema, so the forward body is unchanged.
- src/app/api/services/dario/admin/import-from-omniroute (#8523):
ImportBodySchema for connectionId/alias; invalid shapes fall back to the
same 'connectionId is required' 400 as before.
All four keep their exact status codes and messages — this is a validation
mechanism swap, not a contract change (plugins route suite still 33/33).
Adds tests/unit/route-body-validation-t06.test.ts, which runs the gate's own
rule inside the unit suite so the next such route fails on ITS OWN PR instead
of surfacing weeks later in a base-red sweep. Guard verified by mutation:
renaming .safeParse( in one route makes it fail (1 fail), restored from a
pre-probe copy.
Gates: route-validation:t06, file-size, test-discovery, mutation-test-coverage,
dead-code exit 0; typecheck:core clean; eslint clean.
Refs #9737
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
