mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-19 05:12:16 +03:00
b3f6f697ef
`main` has been red since b342c1a361 on the vitest and integration gates:
✖ tests/unit/autoCombo/provider-family-combos.test.ts > auto/<family>
✖ chat pipeline applies Codex OAuth fingerprint and priority tier inside combos
Both call resetStorage() from beforeEach, which does an fs.rmSync(TEST_DATA_DIR,
{recursive: true, force: true}) with no retry, and intermittently loses the race
with a not-yet-released SQLite handle (ENOTEMPTY).
release/v3.8.51 fixed this in #11968 with a mechanical codemod adding
maxRetries/retryDelay to every recursive rm/rmSync/rmdirSync under tests/, but
that PR landed only on the release branch. Because main only receives work at
the release squash, it stayed broken for the whole cycle — and repo-wide gates
then turn every open PR into main red on checks unrelated to their diff.
This is the --base main twin: re-runs the same codemod that already shipped on
the release branch (scripts/ad-hoc/codemod-rm-maxretries.mjs), so the two
branches converge on identical test-teardown semantics. Test-only; no product
logic is touched.
The remaining three failures reported on #12133 (unit full suite exceeding its
4800s ceiling, package-artifact exceeding 1200s, and the boot-smoke that is
skipped as a consequence) are runner-contention timeouts, not code defects —
validate-release-green.mjs runs those heavy gates concurrently on one shared
hosted runner. There is no fix to port for those.
47 lines
2.3 KiB
TypeScript
47 lines
2.3 KiB
TypeScript
// TDD — 6A.1 triagem do órfão compression-preview-auth.test.ts (503 em vez de 403).
|
|
// Causa-raiz: resetDbInstance()/closeDbInstance() NÃO disparava os resetters do
|
|
// registry stateReset.ts (só o restore de backup.ts disparava). Módulos com estado
|
|
// amarrado à conexão (ex.: apiKeys.ts `_schemaChecked` + prepared statements)
|
|
// ficavam apontando para o schema/conexão antiga: após um segundo reset com DB
|
|
// recriado do zero, ensureApiKeysColumns era pulado (memo de processo) e o
|
|
// re-prepare explodia com "no such column: is_active" → 503 em vez de 403.
|
|
// O mesmo caminho atinge produção via restore de DB antigo sem as colunas-fallback.
|
|
import { test } 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-db-reset-state-"));
|
|
const originalDataDir = process.env.DATA_DIR;
|
|
process.env.DATA_DIR = TEST_DATA_DIR;
|
|
|
|
const core = await import("../../src/lib/db/core.ts");
|
|
const settingsDb = await import("../../src/lib/db/settings.ts");
|
|
const { isValidApiKey } = await import("../../src/sse/services/auth.ts");
|
|
|
|
async function recreateDataDirFromScratch(): Promise<void> {
|
|
core.resetDbInstance();
|
|
fs.rmSync(TEST_DATA_DIR, { recursive: true, force: true, maxRetries: 5, retryDelay: 100 });
|
|
fs.mkdirSync(TEST_DATA_DIR, { recursive: true });
|
|
// Primeiro acesso recria o DB do zero (migrations + colunas-fallback).
|
|
await settingsDb.updateSettings({ requireLogin: true, setupComplete: true });
|
|
}
|
|
|
|
test("api-key validation survives a second resetDbInstance with a recreated DB (module state resetters fire)", async () => {
|
|
await recreateDataDirFromScratch();
|
|
assert.equal(await isValidApiKey("not-a-real-key"), false);
|
|
|
|
// Segundo ciclo: sem o wiring resetDbInstance→resetAllDbModuleState, o memo de
|
|
// schema de apiKeys.ts sobrevive ao reset e o prepare lança "no such column".
|
|
await recreateDataDirFromScratch();
|
|
assert.equal(await isValidApiKey("not-a-real-key"), false);
|
|
});
|
|
|
|
test.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;
|
|
});
|