Files
OmniRoute/tests/unit/repro-6524.test.ts
Diego Rodrigues de Sa e Souza adb1fc5b27 fix(providers): honor max_token capability override in reasoning buffer clamp (#6524) (#6904)
getExplicitModelOutputCap() (the clamp ceiling used by
resolveReasoningBufferedMaxTokens) only ever read the unvalidated synced
limit_output / registry / static-spec chain — it ignored the operator-settable
max_token capability override that getResolvedModelCapabilities() already
consulted. When a provider's synced catalog row reports a wrong limit_output
(e.g. ollama-cloud/deepseek-v4-flash: limit_output=1048576, same as
limit_context, while the real upstream cap is 65536), the reasoning-buffer
clamp trusted the bad number and inflated max_tokens 64000 -> 96000, which
upstream rejected with "exceeds model's maximum output tokens (65536)".

The override table (model_capability_overrides, "max_token" key,
/api/model-capability-overrides) is the existing, already-shipped remediation
path for exactly this class of bad catalog data, but reasoningTokenBuffer.ts
had no way to benefit from it. Extracted the override lookup into a shared
getMaxTokenCapabilityOverride() helper and made getExplicitModelOutputCap()
consult it first, so both read paths now agree.
2026-07-11 11:22:15 -03:00

104 lines
4.2 KiB
TypeScript

/**
* Regression test for issue #6524.
*
* Reporter observed: for `ollama-cloud/deepseek-v4-flash`, a synced capability row
* with `limit_output=1048576` (wrongly equal to `limit_context`, while the real
* upstream output cap is `65536`) caused the reasoning-token-buffer heuristic to
* expand `max_tokens` 64000 -> 96000, which upstream rejected with
* "exceeds model's maximum output tokens (65536)".
*
* Root cause (confirmed by reading `resolveReasoningBufferedMaxTokens` and its
* `getExplicitModelOutputCap` clamp source): the clamp math itself is correct, but
* `getExplicitModelOutputCap()` only ever read the unvalidated synced
* `limit_output` (or registry/static fallbacks) — it ignored the operator-settable
* `max_token` capability override (`src/lib/db/modelCapabilityOverrides.ts`,
* `/api/model-capability-overrides`) that `getResolvedModelCapabilities()` already
* consulted. That inconsistency meant an operator manually correcting a bad synced
* output cap (the existing, already-shipped remediation path for wrong catalog
* data) had no effect on the reasoning buffer, which kept inflating past the real
* cap regardless.
*
* Fix: `getExplicitModelOutputCap()` now checks the same `max_token` override
* before falling back to synced/registry/static data, via a helper shared with
* `getResolvedModelCapabilities()`.
*/
import assert from "node:assert/strict";
import test from "node:test";
import fs from "node:fs";
import os from "node:os";
import path from "node:path";
const TEST_DATA_DIR = fs.mkdtempSync(path.join(os.tmpdir(), "omniroute-repro-6524-"));
process.env.DATA_DIR = TEST_DATA_DIR;
const core = await import("../../src/lib/db/core.ts");
const { saveModelsDevCapabilities, clearModelsDevCapabilities } = await import(
"../../src/lib/modelsDevSync.ts"
);
const { setModelCapabilityOverride, removeModelCapabilityOverride } = await import(
"../../src/lib/db/modelCapabilityOverrides.ts"
);
const { resolveReasoningBufferedMaxTokens } = await import(
"../../open-sse/services/reasoningTokenBuffer.ts"
);
const PROVIDER = "ollama-cloud";
const MODEL = "deepseek-v4-flash";
const TARGET = `${PROVIDER}/${MODEL}`;
const REAL_UPSTREAM_OUTPUT_CAP = 65536; // per reporter's boundary test table
function capabilityEntry(limitContext: unknown, overrides: Record<string, unknown> = {}) {
return {
reasoning: false,
tool_call: true,
attachment: false,
temperature: true,
structured_output: true,
limit: { context: limitContext, output: limitContext },
...overrides,
};
}
test.before(() => {
clearModelsDevCapabilities();
// Mirrors the exact production row from the issue: limit_context and limit_output
// both wrongly synced to 1048576 for ollama-cloud/deepseek-v4-flash, while the real
// upstream output cap (per the reporter's boundary test) is 65536.
saveModelsDevCapabilities({
[PROVIDER]: {
[MODEL]: capabilityEntry(1048576, { reasoning: true, limit_output: 1048576 }),
},
});
});
test.after(() => {
core.resetDbInstance();
fs.rmSync(TEST_DATA_DIR, { recursive: true, force: true });
});
test("#6524: with only the (wrong) synced catalog data, the buffer still inflates past the real cap", () => {
// Documents the known, out-of-scope limitation: nothing in our codebase can
// psychically know the real upstream cap before an operator (or a future
// self-healing mechanism) supplies a correction. This is the reported symptom's
// starting state, not something this fix promises to eliminate on first contact.
const result = resolveReasoningBufferedMaxTokens(TARGET, 64000);
assert.equal(result, 96000);
});
test("#6524: an operator-set max_token override now clamps the reasoning buffer to the real cap", () => {
assert.ok(
setModelCapabilityOverride(TARGET, "max_token", REAL_UPSTREAM_OUTPUT_CAP),
"expected the max_token override to be written"
);
try {
const result = resolveReasoningBufferedMaxTokens(TARGET, 64000);
assert.ok(
result === null || result <= REAL_UPSTREAM_OUTPUT_CAP,
`expected max_tokens to stay <= ${REAL_UPSTREAM_OUTPUT_CAP}, got ${result} ` +
`(reproduces reported 64000 -> 96000 inflation, upstream then 400s)`
);
} finally {
removeModelCapabilityOverride(TARGET, "max_token");
}
});