mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-21 14:22:14 +03:00
3d4f3e4960
* test(infra): retry recursive temp-dir removal instead of failing a shard on ENOTEMPTY (#11966) Two shards on release/v3.8.51 went red in one day with the same signature — "ENOTEMPTY, Directory not empty: /tmp/omniroute-<test>-XXXXXX" — from combo-same-provider-cascade (Unit Tests fast-path 4/4, on a PR that touches only .github/) and auth-policy-embeddings-webfetch-7785 (the 20k-test TIA step). Both pass alone and on re-run: the cleanup races something still writing into the directory (SQLite WAL/-shm checkpoint, a worker, the backup) and under a loaded hosted runner the window opens. 1154 test files do their own cleanup with fs.rmSync(dir, { recursive: true, force: true }); 57 already asked for retries. One-shot codemod (scripts/ad-hoc/codemod-rm-maxretries.mjs, kept for the record): every rm / rmSync / rmdirSync option object with `recursive: true` and no `maxRetries` gains `maxRetries: 5, retryDelay: 100` — Node itself then retries ENOTEMPTY/EBUSY/EPERM for up to ~0.5 s before giving up. 2243 call sites in 1292 files under tests/, the shared tests/_setup/isolateDataDir.ts exit hook included. Only the option object changes: no call site, assertion or import is touched. Validation: prettier and ESLint (with the frozen suppressions) clean on all 1292 files; a random 20-file sample runs green (quota-redis-store hangs identically on the untouched tree — it needs a Redis on localhost, an environment matter). The four unit shards on this PR are the full run. * fix(quality): let check-forgotten-sibling-tests read a 1,000-file diff The gate shells out to `git diff` through execFileSync with Node's default 1 MB maxBuffer; the 1,292-file codemod in this PR is the first diff large enough to overflow it, and the gate died with `spawnSync git ENOBUFS` before comparing anything. 64 MB is far above any real PR and costs nothing when unused.
68 lines
2.8 KiB
TypeScript
68 lines
2.8 KiB
TypeScript
/**
|
|
* Regression test for a migration version-numbering collision: two files,
|
|
* 135_connection_runtime_state.sql (#9449, landed 2026-08-07) and
|
|
* 135_migrate_model_capability_max_token.sql (#8908, landed 2026-08-05),
|
|
* both claimed version "135" — #9449 branched before #8908 merged and never
|
|
* got renumbered before landing on release/v3.8.50.
|
|
*
|
|
* This is not a cosmetic issue: `getMigrationFiles()` throws
|
|
* "Migration version collision detected" the moment ANY code path first
|
|
* touches the database (getDbInstance() -> runMigrations()), which means a
|
|
* completely fresh install/deploy from this branch cannot even boot —
|
|
* confirmed live against a freshly built container.
|
|
*
|
|
* Fix: renumbered the later-landing file to 140 (the next free slot) and
|
|
* added the matching isSchemaAlreadyApplied("140") retroactive guard
|
|
* (migrationRunner.ts), matching the established pattern already used for
|
|
* the prior 135/136 -> 137/138 renumber in the same file.
|
|
*/
|
|
import { test, before, after } from "node:test";
|
|
import assert from "node:assert/strict";
|
|
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-migration-135-"));
|
|
const originalDataDir = process.env.DATA_DIR;
|
|
process.env.DATA_DIR = TEST_DATA_DIR;
|
|
|
|
let core: typeof import("../../src/lib/db/core.ts");
|
|
|
|
before(async () => {
|
|
core = await import("../../src/lib/db/core.ts");
|
|
});
|
|
|
|
after(() => {
|
|
core.resetDbInstance();
|
|
fs.rmSync(TEST_DATA_DIR, { recursive: true, force: true, maxRetries: 5, retryDelay: 100 });
|
|
if (originalDataDir === undefined) delete process.env.DATA_DIR;
|
|
else process.env.DATA_DIR = originalDataDir;
|
|
});
|
|
|
|
test("a fresh install applies all real on-disk migrations without a version collision", () => {
|
|
// getDbInstance() runs every migration file under src/lib/db/migrations/
|
|
// against a brand-new, empty SQLite file — the exact scenario a fresh
|
|
// deploy hits. Before the fix this threw synchronously here.
|
|
assert.doesNotThrow(() => core.getDbInstance());
|
|
});
|
|
|
|
test("both formerly-135 migrations' tables exist after a fresh install", () => {
|
|
const db = core.getDbInstance();
|
|
const tableNames = (
|
|
db.prepare("SELECT name FROM sqlite_master WHERE type = 'table'").all() as Array<{
|
|
name: string;
|
|
}>
|
|
).map((row) => row.name);
|
|
|
|
// From 135_connection_runtime_state.sql (renumbered to 140).
|
|
assert.ok(
|
|
tableNames.includes("connection_runtime_state"),
|
|
"connection_runtime_state table must exist"
|
|
);
|
|
// From 135_migrate_model_capability_max_token.sql (kept at 135) — this
|
|
// migration only mutates existing model_capabilities rows, so its
|
|
// observable effect is that the migration completed, not a new table;
|
|
// provider_connections already exists as its target table.
|
|
assert.ok(tableNames.includes("provider_connections"), "sanity: base schema applied");
|
|
});
|