Files
msd-core/tests/helpers/git-fixture.cjs
Tom Boucher 7a7bf19fc1 enhance(#2872): record scope and runtime in the install manifest (#3323)
* 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>
2026-08-10 15:50:55 -04:00

182 lines
8.6 KiB
JavaScript

'use strict';
/**
* git-fixture — the shared throw-on-failure mechanism for process-seam
* results, its non-throwing counterpart, plus a throw-preserving wrapper
* over the seam's `runGit`.
*
* Why this exists: `execSync`/`execFileSync` throw on any non-zero exit,
* and 237+ sites in this repo's test suite are written against that throw —
* they read `err.status`, `err.stdout`, `err.stderr`. `tests/helpers/
* process-seam.cjs` deliberately never throws (see its own header): every
* outcome, including a non-zero exit, a timeout, or a spawn failure, comes
* back as data on a discriminated-union result. Migrating a throwing
* `execSync`/`execFileSync` call site straight onto the seam without this
* wrapper would silently turn a loud test failure (an uncaught throw) into
* a quiet one (a result object nobody checked) — exactly the kind of
* regression a migration must not introduce.
*
* `throwIfFailed` is that mechanism: given any process-seam result and a
* human-readable name for what ran, it throws in the shape the legacy
* `execSync`/`execFileSync` idiom produced, with the seam's typed fields
* attached alongside it — or returns quietly on a clean exit. `gitOrThrow`
* is `throwIfFailed` specialized to `runGit`. Every other local test helper
* that needs the same throw-on-failure bridge (over `runNode`, `runHook`,
* etc.) calls `throwIfFailed` directly instead of hand-rolling its own copy
* of this shape — five call sites did exactly that before this module
* exported it, and drifted from each other in the process (#3144).
*
* `toLegacyResult` is the non-throwing sibling: call sites that already
* branch on exit status as data (never wanted a throw) still need the
* result reshaped onto the legacy `{ status, stdout, stderr }` field names
* their assertions read — ~8 test files hand-rolled that identical mapping
* before this module exported it too (#3147).
*
* `tests/helpers/process-seam.cjs` itself is NOT modified by this module —
* its never-throws contract is intact; this is a layer on top, not a change
* underneath.
*/
const { runGit, OUTCOME } = require('./process-seam.cjs');
/**
* Default timeout for `gitOrThrow` calls, in milliseconds.
*
* 15000ms: these are git plumbing operations (rev-parse, branch, log, ...)
* against a small mkdtemp fixture repo — well over any observed local/CI
* duration for that class of call, and far under the seam's own 60000ms
* default so a hung git surfaces fast instead of riding out the seam's full
* budget.
*/
const DEFAULT_GIT_TIMEOUT_MS = 15000;
/**
* Timeout for git calls that CONSTRUCT a fixture repository, in milliseconds.
*
* A distinct class from `DEFAULT_GIT_TIMEOUT_MS` above, which is sized for
* plumbing READS (rev-parse, branch, log) against an existing repo.
* `createFixture` (`tests/fixtures/index.cjs`) issues SIX sequential spawns to
* build one repo — `init`, three `config` writes, `add -A`, `commit` — and
* `init`/`commit` each write dozens of files. On Windows every one of those
* spawns is Defender-scanned, so the construction sequence is materially
* heavier than any single read.
*
* CI (PR #3323, `full test (windows-latest, 22, shard 2/3)`) recorded
* `gitOrThrow: git init failed — outcome=timed_out exitCode=null` and the same
* for `git commit --allow-empty`, with sibling tests in the same block taking
* 15.6-22.0s, 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: the identical conclusion, in the identical job,
* that `HOOK_FANOUT_TIMEOUT_MS` records for PR #3285.
*
* 60000ms is 4x the bound that failed and half `INSTALL_TIMEOUT_MS` — the same
* ratio `HOOK_FANOUT_TIMEOUT_MS` uses, and the right order for a call that is
* far heavier than a plumbing read but much lighter than a full installer run.
*/
const GIT_FIXTURE_TIMEOUT_MS = 60000;
/**
* Throw on anything other than a clean (exit 0) process-seam result,
* preserving the legacy `execSync`/`execFileSync` throw-on-failure idiom
* that existing test code is written against. Returns quietly (no return
* value) on a clean exit — callers that need `stdout` read it off `result`
* themselves; this only decides whether to throw.
*
* @param {object} result - a process-seam result: `{outcome, exitCode,
* stdout, stderr, timedOut, signal}` (plus any seam-specific fields,
* e.g. `code`, which are ignored here).
* @param {string} displayName - human string naming what ran, e.g.
* `'git commit -m seed'` or `'bash <quick-guard snippet>'`. Embedded in
* the thrown message so failures are attributable at a glance.
* @throws {Error} On any non-zero exit, timeout, kill, or spawn failure.
* The thrown error carries, as own properties:
* - `status` — the exit code (the legacy `execSync`/`execFileSync` name;
* this repo's migrated catch blocks read `err.status`, e.g.
* tests/worktree-safety.test.cjs:1361, tests/read-guard.test.cjs:160,
* tests/security-scan.security.test.cjs:201).
* - `exitCode` — the same value as `status` (the seam's own name; both
* are aliases on purpose, not a rename).
* - `stdout`, `stderr` — strings.
* - `signal` — the seam's `signal` field.
* - `timedOut` — the seam's `timedOut` field.
* - `outcome` — the seam's `OUTCOME` discriminant.
*/
function throwIfFailed(result, displayName) {
if (result.outcome === OUTCOME.EXITED && result.exitCode === 0) {
return;
}
const err = new Error(
`${displayName} failed — outcome=${result.outcome} exitCode=${result.exitCode} ` +
`stderr=${result.stderr.trim()}`
);
err.status = result.exitCode;
err.exitCode = result.exitCode;
err.stdout = result.stdout;
err.stderr = result.stderr;
err.signal = result.signal;
err.timedOut = result.timedOut;
err.outcome = result.outcome;
throw err;
}
/**
* Run `git` via the process seam and throw on anything other than a clean
* exit, preserving the legacy `execSync`/`execFileSync` throw-on-failure
* idiom that existing test code is written against.
*
* @param {string[]} args - argv passed to git (never shell-interpreted).
* @param {object} [options] - forwarded to `runGit`; see process-seam.cjs.
* `options.timeoutMs`, if provided, overrides `DEFAULT_GIT_TIMEOUT_MS`.
* @returns {string} `stdout` on a clean (exit 0) run.
* @throws {Error} See `throwIfFailed` for the exact shape thrown.
*/
function gitOrThrow(args, options = {}) {
// Destructure (not spread-after) so an explicit `timeoutMs: undefined` in
// `options` still resolves to the default: a destructure default applies
// on `undefined`, whereas `{ timeoutMs: DEFAULT, ...options }` would let
// an own `undefined` key silently overwrite it and fall through to the
// seam's much larger default timeout.
const { timeoutMs = DEFAULT_GIT_TIMEOUT_MS, ...rest } = options;
const r = runGit(args, { ...rest, timeoutMs });
throwIfFailed(r, `gitOrThrow: \`${['git', ...args].join(' ')}\``);
return r.stdout;
}
/**
* The NON-throwing counterpart to `throwIfFailed`: maps any process-seam
* result onto the legacy `execSync`/`execFileSync` `{ status, stdout,
* stderr }` shape, without ever throwing. For call sites that already read
* exit status as data (they branch on `.status`/`.stdout`/`.stderr`
* themselves) rather than wanting a throw on failure — the same "the shape
* is defined once rather than re-derived per suite" motivation as
* `throwIfFailed`, just for the non-throwing half of the split. Before this
* export existed, ~8 test files hand-rolled the identical three-line mapping
* (#3147 pre-PR review finding).
*
* This is intentionally a bare mapping and nothing more: some call sites
* layer additional site-specific behavior on top (an extra field, a parsed
* JSON body in place of raw `stdout`, etc.) — those compose `toLegacyResult`
* as a building block (e.g. `{ ...toLegacyResult(result), extra }`) rather
* than folding their extra behavior into this helper, so this shape stays
* exactly one thing everywhere it's used.
*
* @param {object} result - a process-seam result: `{outcome, exitCode,
* stdout, stderr, timedOut, signal}` (plus any seam-specific fields).
* @returns {{status: number|null, stdout: string, stderr: string}} —
* `status` is the legacy `spawnSync`/`execFileSync` field name for
* `result.exitCode`; `stdout`/`stderr` pass through unchanged.
*/
function toLegacyResult(result) {
return { status: result.exitCode, stdout: result.stdout, stderr: result.stderr };
}
module.exports = {
gitOrThrow,
throwIfFailed,
toLegacyResult,
DEFAULT_GIT_TIMEOUT_MS,
GIT_FIXTURE_TIMEOUT_MS,
};