7a7bf19fc1
* enhance(#2872): record scope and runtime in the install manifest gsd-file-manifest.json gains manifestVersion, runtime and scope, and a new read-only Installed Surface Resolver Module reads both install scopes for a runtime in one call -- the first code path in the repo that does. Phase 3 of epic #2866 (ADR-2866). Blocks Phase 4 (#2873), which resolves #2218: the resolver's shadowedBy field is that defect expressed as a value for the first time. It ships computed-and-unread here. Installed-ness is decided by manifest PRESENCE, never by the new fields, so a manifest written by an older GSD stays fully functional and no user needs to reinstall. Recorded runtime/scope are corroboration: a disagreement with the probed config dir is reported as declaredScopeMatchesProbe: false, never silently corrected. readInstallManifest is widened additively -- version/timestamp/mode/files keep their exact names, types and meanings for all four existing callers. manifestVersion is a new field rather than a reinterpretation of version, which holds the package version and is read by the golden-parity fixtures. Stems are derived from the installed manifest's own file keys, the inverse of Phase 2's filename composition, guarded by a fast-check round-trip property plus a kebab-case charset check so a crafted manifest key cannot put a traversal segment, control character or ANSI escape into a trigger that Phase 4 renders back to the user. Also fixes two defects found while working: - bin/install.js hardcoded manifestVersion: 2 while the reader owned MANIFEST_SCHEMA_VERSION = 2. Now single-sourced, with a parity test. - docs/installer-migrations.md documented an install-state schema of five snake_case fields that have never been written; InstallState has only ever been { schemaVersion, appliedMigrations }. Corrected with a dated note. Verification runs on the remote runner. * fix(#2872): fold review findings from three independent engines Standards axis: - convert the manifest-schema suite from a hybrid setup(t) closure to beforeEach/afterEach (CONTRIBUTING.md:319-354 Pattern 1). The hybrid was neither approved pattern and a new test forgetting the call got no warning. - SCOPE_ORDER was declared twice with no parity test -- this repo's recorded generative-fix-divergence class. Give the ordering one owner: install-scope exports it frozen, the layout module and the resolver both import it, and a test locks it against scopeRank so the constant and the ranks cannot drift. - drop the defaultReadManifest passthrough (Middle Man). Spec axis: - add the VOLATILE_FILES exclusion test and source comment the acceptance table promised and did not deliver. gsd-file-manifest.json stays excluded: the new fields are deterministic, but timestamp -- the original reason -- is unchanged. Security axis: - bound the reported manifest runtime at 64 chars, matching the truncatePostureValue convention already used in this subsystem. It reached declaredRuntime unbounded while the adjacent stems were gated by SAFE_STEM; an inconsistent posture on the same attacker-influenceable document. The charset stays ungated on purpose -- declaredRuntimeMatchesProbe needs to see the real value -- so Phase 4 must sanitize before rendering, recorded in the design's Known limits. Both new parity tests were verified to FAIL when the two sides are made to disagree, then pass again on revert. Verification runs on the remote runner. * chore(#2872): backfill changeset pr number to 3323 * fix(#2872): give git fixture construction its own timeout class PR #3323's full test (windows-latest, 22, shard 2/3) failed with gitOrThrow: 'git init' failed -- outcome=timed_out exitCode=null gitOrThrow: 'git commit --allow-empty' failed -- outcome=timed_out from drift-detection.test.cjs's beforeEach, a file this branch never touched. Every other lane passed the same commit, including windows-latest node 24 on all three shards, and next is green. Root cause is a bound sized for the wrong class. DEFAULT_GIT_TIMEOUT_MS is 15000 and its own comment scopes it to plumbing READS -- rev-parse, branch, log -- against an existing repo. createFixture uses it for six sequential repo-CONSTRUCTION spawns: init, three config writes, add -A, commit. init and commit each write dozens of files, and on Windows every spawn is Defender-scanned. Sibling tests in the failing block took 15.6-22.0s against a 15000ms bound. This repo already diagnosed this exact shape once: timeouts.cjs's HOOK_FANOUT_TIMEOUT_MS records PR #3285 failing in the SAME job with the SAME outcome=timed_out exitCode=null signature at the SAME bound while every other lane passed, and concludes 'a bound sized for the wrong class, not a slow machine'. It was fixed by splitting out a heavier class-norm at 60000. Same remedy here: GIT_FIXTURE_TIMEOUT_MS = 60000, 4x the bound that failed and half INSTALL_TIMEOUT_MS. DEFAULT_GIT_TIMEOUT_MS deliberately stays at 15000 -- a blanket raise would stop a genuinely hung plumbing read from surfacing fast. Verified the value reaches the spawn rather than being an ignored option: spawnSync was monkeypatched before requiring the fixture module, and all six git construction calls were captured carrying timeout: 60000. This branch's two new test files shift shard composition, which is how a pre-existing fragility landed in the heaviest shard on the slowest lane. Fixed here rather than deferred, per the no-defer rule. Verification runs on the remote runner. --------- Co-authored-by: sim <sim@local>
97 lines
4.0 KiB
JavaScript
97 lines
4.0 KiB
JavaScript
'use strict';
|
|
|
|
/**
|
|
* Shared CLASS-NORM subprocess timeouts for the test suite (#3145 pre-PR
|
|
* review finding).
|
|
*
|
|
* These four values are not per-suite fixture bindings — each is a fact
|
|
* about how long a CLASS of subprocess call takes, derived from observed
|
|
* bench behavior. Before this module existed, all four were hand-copied
|
|
* across dozens of files with the same justifying comment restated each
|
|
* time (52 copies across this wave's diff alone), so the norm could drift
|
|
* silently the next time it moved — as `INSTALL_TIMEOUT_MS` already did
|
|
* once, from 60000 to 120000, after a real bench `ETIMEDOUT`. Import from
|
|
* here instead of re-declaring.
|
|
*
|
|
* This module is for the shared norms ONLY. A call site that genuinely
|
|
* differs from its class (e.g. a real `tsc` compile in
|
|
* tests/ensure-runtime-build.test.cjs, or a `regen:derived` run in
|
|
* tests/fragment-single-edit-propagation.install.test.cjs) keeps its own
|
|
* local constant with its own justifying comment — do not force those
|
|
* sites onto a shared value that doesn't describe them.
|
|
*/
|
|
|
|
const { DEFAULT_GIT_TIMEOUT_MS, GIT_FIXTURE_TIMEOUT_MS } = require('./git-fixture.cjs');
|
|
|
|
/**
|
|
* A single short CLI query or `node -e` probe against a temp fixture —
|
|
* e.g. reading back a version string or a small piece of emitted state.
|
|
* 15000ms is well over any observed duration for that class of call.
|
|
*/
|
|
const PROBE_TIMEOUT_MS = 15000;
|
|
|
|
/**
|
|
* A git-hook invocation that FANS OUT to nested shell subprocesses — the hook
|
|
* itself under `bash`, plus every helper it shells to. The prepush guard is the
|
|
* worked example: it runs a mock `git` that is also a bash script, so a single
|
|
* `runHook` is roughly four Git Bash spawns.
|
|
*
|
|
* This is a heavier class than `PROBE_TIMEOUT_MS`, and the difference is
|
|
* Windows-shaped. Each spawn there is Defender-scanned, and the first hook test
|
|
* in a file pays cold start on top. CI (PR #3285, `full test (windows-latest,
|
|
* 22, shard 2/3)`) recorded `outcome=timed_out exitCode=null` at exactly the
|
|
* 15000ms probe bound while every other lane — including windows-latest node 24,
|
|
* all three shards — passed the same commit. That is a bound sized for the wrong
|
|
* class, not a slow machine.
|
|
*
|
|
* 60000ms is 4x the bound that failed and half `INSTALL_TIMEOUT_MS`, which is
|
|
* the right order: a hook fan-out is much lighter than a full installer run but
|
|
* far heavier than reading back a version string.
|
|
*
|
|
* Sites that invoke a hook doing NO subprocess fan-out should stay on
|
|
* `PROBE_TIMEOUT_MS` — this norm describes the fan-out shape, not `runHook` in
|
|
* general.
|
|
*/
|
|
const HOOK_FANOUT_TIMEOUT_MS = 60000;
|
|
|
|
/**
|
|
* Git plumbing (rev-parse, branch, log, ...) against a small mkdtemp
|
|
* fixture repo. Re-exports `tests/helpers/git-fixture.cjs`'s
|
|
* `DEFAULT_GIT_TIMEOUT_MS` rather than restating the literal, so the two
|
|
* can never disagree.
|
|
*/
|
|
const GIT_TIMEOUT_MS = DEFAULT_GIT_TIMEOUT_MS;
|
|
|
|
/**
|
|
* Git fixture CONSTRUCTION calls (init/config/add/commit) — a heavier class
|
|
* than `GIT_TIMEOUT_MS`. See `tests/helpers/git-fixture.cjs`'s
|
|
* `GIT_FIXTURE_TIMEOUT_MS` for the full rationale (PR #3323); re-exported
|
|
* here rather than restated so the two can never disagree.
|
|
*/
|
|
|
|
/**
|
|
* Hooks bundling via `scripts/build-hooks.js` (not a full project build —
|
|
* see per-site comments for sites that run a heavier build and therefore
|
|
* keep a larger local value). 30000ms is well over any observed duration
|
|
* for a hooks-only bundle pass.
|
|
*/
|
|
const BUILD_TIMEOUT_MS = 30000;
|
|
|
|
/**
|
|
* A full `bin/install.js` run. Idle runs measure 13-30s; a load-tested
|
|
* bench recorded a real `spawnSync ETIMEDOUT` at a 60000ms cap
|
|
* (tests/install.test.cjs:5505-5513) while another lane passed the SAME
|
|
* commit in 12.7s — 60000 is too tight for this class of spawn under
|
|
* load. 120000ms is the load-tested norm.
|
|
*/
|
|
const INSTALL_TIMEOUT_MS = 120000;
|
|
|
|
module.exports = {
|
|
PROBE_TIMEOUT_MS,
|
|
HOOK_FANOUT_TIMEOUT_MS,
|
|
GIT_TIMEOUT_MS,
|
|
GIT_FIXTURE_TIMEOUT_MS,
|
|
BUILD_TIMEOUT_MS,
|
|
INSTALL_TIMEOUT_MS,
|
|
};
|