1a3e68de5d
Establish an inert PostgreSQL setup signal and repeatable evidence tooling without changing harness behavior. - add explicit setup participation semantics and inertness coverage - survey Vitest setup boundaries with isolated report-only fixtures - bound interleaved campaigns by process group and campaign deadline - reject missing backend samples and enable candidate diagnostics - document the rejected boundary result and successor protocol Files changed: .../test-failures/postgres-ddl-admission-bound.md | 15 ++ docs/testing.md | 10 ++ packages/core/package.json | 2 +- .../src/__test-utils__/pg-setup-participation.ts | 22 +++ .../src/__tests__/pg-setup-participation.test.ts | 21 +++ .../__tests__/vitest-setup-pg-inertness.test.ts | 10 ++ packages/core/vitest.pg.config.ts | 10 ++ .../__tests__/pg-preadmission-campaign.test.mjs | 63 +++++++ scripts/__tests__/pg-setup-boundary-probe.test.mjs | 92 ++++++++++ scripts/pg-preadmission-campaign.mjs | 194 +++++++++++++++++++++ scripts/pg-setup-boundary-probe.mjs | 182 +++++++++++++++++++ 11 files changed, 620 insertions(+), 1 deletion(-) Fusion-Task-Id: FN-9139 Fusion-Task-Lineage: 2cf8ccbf-37f9-4fdc-8e8f-326df823e1cd Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
56 lines
2.4 KiB
TypeScript
56 lines
2.4 KiB
TypeScript
import { defineConfig, mergeConfig } from "vitest/config";
|
|
|
|
import baseConfig from "./vitest.config";
|
|
import { computeMaxWorkers } from "./src/__test-utils__/vitest-workers";
|
|
|
|
/*
|
|
FNXC:PgTestWorkerCap 2026-07-18-18:00:
|
|
FNXC:PgTestDdlAdmission 2026-08-16-20:30:
|
|
FN-9130 retained the advisory primitive's deterministic coverage and reverted
|
|
both regressive admission and deferred-reaper experiments after loaded measurements. This cap remains a
|
|
separate gate-shape policy; keep PG_MAX_WORKERS unchanged.
|
|
|
|
Dedicated vitest config for the PostgreSQL gate suite (`test:pg-gate`). The
|
|
pg-gate runs ONLY *.pg.test.ts files, each of which builds and copies a
|
|
per-file schema-template database (heavy CREATE/DROP DATABASE DDL that the one
|
|
shared Postgres server serializes). The bottleneck is that single DB, not CPU,
|
|
so fork fan-out must not scale with core count.
|
|
|
|
The base core config derives its worker count from CPUs: on a 28-core dev box
|
|
that is 6 forks. Six concurrent forks racing the DDL-heavy per-file setup
|
|
oversubscribe the one Postgres until every `beforeAll` exceeds the 15s
|
|
hookTimeout, and the whole gate reports 23/23 hook timeouts. CI's low-core
|
|
runners land near 2 forks and pass, so the failure only bites high-core local
|
|
machines. Measured on this 28-core box: 6 forks -> all time out; 4 forks -> 23
|
|
files / 126 tests pass in ~42s; 2 forks -> pass in ~78s.
|
|
|
|
`maxCap: 4` pins a DB-safe ceiling: high-core machines clamp to 4 forks while
|
|
low-core machines keep their smaller CPU-derived count (min(4, cpuCap)). This
|
|
is NOT timeout appeasement — the hookTimeout is unchanged; we right-size
|
|
concurrency to the actual constraint (a single shared Postgres) per the FN-5048
|
|
rule against oversubscribing worker/concurrency knobs. Only the pg-gate uses
|
|
this config; the interleaved full core suite is unaffected because pg files are
|
|
a small fraction of it and rarely run 6-at-once.
|
|
*/
|
|
const PG_MAX_WORKERS = 4;
|
|
|
|
export default mergeConfig(
|
|
baseConfig,
|
|
defineConfig({
|
|
test: {
|
|
/*
|
|
FNXC:PgTestPreAdmission 2026-08-17-03:38:
|
|
FN-9139 requires the dedicated PostgreSQL config to explicitly identify
|
|
its participating lane. The shared setup stays inert everywhere else,
|
|
while plain invocations can still opt in through the same environment
|
|
variable without relying on this config.
|
|
*/
|
|
env: {
|
|
FUSION_PG_TEST_SETUP_PARTICIPANT: "1",
|
|
},
|
|
maxWorkers: computeMaxWorkers({ maxCap: PG_MAX_WORKERS }),
|
|
minWorkers: 1,
|
|
},
|
|
}),
|
|
);
|