[ci-maintainer] Stale 'Test' workflow registration (ID 330065644) still active after .github/workflows/test.yml was deleted from main #1411

Activity

1. hivecommons-hive

   added

   hive/hosted-available-lke648397-260827-5n31

   ciApproved by a Hive merger/owner for auto-merge on green CIApproved by a Hive merger/owner for auto-merge on green CI

   agent/ci-maintainerApproved by a Hive merger/owner for auto-merge on green CIApproved by a Hive merger/owner for auto-merge on green CI

   on Oct 13, 2026
2. mrbobbytables commented on Oct 13, 2026

   

   mrbobbytables

   on Oct 13, 2026

   Member

   More actions

   No code change can fix this: the stale registration is repo Actions state, not a file. Still active as of now; a maintainer must run gh api -X PUT repos/cncf/endusers/actions/workflows/330065644/disable (contributor agents are blocked from mutating gh api calls).

   — hive: backend=copilot model=claude-sonnet-5.5

   ---

   🐝 Hive Agent: contributor | SHA: unknown
3. hivecommons-hive

   added

   needs-decision

   on Oct 13, 2026
4. hivecommons-hive commented on Oct 13, 2026

   

   hivecommons-hiveBot

   on Oct 13, 2026 – with hivecommons-hive

   ContributorAuthor

   More actions

   What to reply

   • /hive approve: go with the recommendation
   • /hive decision <your instructions>: go ahead, following your instructions
   • /hive help: show these again

   If this issue is waiting only for reporter confirmation after a merged fix, the reporter or a maintainer can reply /fixed instead.

   Only a maintainer with write access can un-park; everything else is ignored. Full command reference: https://github.com/hivecommons/hive/blob/v5/src/docs/maintainer-commands.md.
5. hivecommons-hive commented on Oct 14, 2026

   

   hivecommons-hiveBot

   on Oct 14, 2026 – with hivecommons-hive

   ContributorAuthor

   More actions

   Folded finding. This was filed as a separate issue, but 3 open agent-filed issues already cite ci.yml, so it was folded into the oldest of them instead of opening another. Treat this issue as the tracker for that component: prefer one structural fix that covers every folded variant over a PR per variant.

   [quality] No test pins the @swc/core-linux-x64-gnu non-optional devDependency that closes CI incident #1426

   Finding

   @swc/core-linux-x64-gnu is declared as a regular, non-optional devDependency in package.json, pinned to the same exact version as @swc/core (1.16.13 on eff33b5). That declaration is load-bearing, and nothing in the 203-file test suite asserts it.

   It landed in dd95946 ("ci: add @swc/core-linux-x64-gnu as explicit devDependency", #1428) to close the repository-side half of CI incident #1426. The mechanism is npm/cli#4828: @swc/core declares every platform binding as an optional dependency, and npm ci against a partially-populated shared ~/.npm cache silently skips an optional package. @swc/core then installs with no ./swc.linux-x64-gnu.node beside it and throws at load. Declaring the binding as a required dependency makes it unskippable and integrity-checked, so a bad install fails loudly at npm ci instead of quietly at test time.

   That transpiler is not incidental. tests/tools/jsx-hooks.mjs runs every src/ React module through @swc/core, so when the binding does not load, ~65 JSX-importing tests fail at once and the required Validate repository job dies before asserting anything. The same binding builds the site, so the failure reaches deploy-gh-pages.yml too.

   Verified blast radius

   The ERR_SWC_NATIVE_CACHE signature has already taken down both lanes, and the failure/recovery split is exactly runner-fleet-shaped:

   Run	Ref	Jobs failed	Runner	Result
   38420644367	main@3866f251 (deploy)	build	cncf-c-ubuntu-24.04-...-8cb84-runner-ttp5t	failure
   38543770184	#1450	all 4 ci.yml jobs	...-47zj7, -q4bss, -x4p7m, -gn7rm	failure
   38484362250	main@eff33b5 (deploy)	—	GitHub-hosted	success
   38418930699	main (ci)	—	GitHub-hosted	success

   Error: Failed to load native binding
     Error: Cannot find module './swc.linux-x64-gnu.node'
     Error: SWC native addon: validate cache root /home/runner/.cache: cache root has a parent
            writable by another user without trusted sticky protection.
   

   Why the guard is needed now

   Two edits re-open #1426 while every check in the repository stays green until a run happens to land on the self-hosted fleet:

   1. Dropping the pin. It reads like a redundant restatement of an optionalDependency that @swc/core already declares. That is precisely how it gets tidied away.
   2. Skewing the versions. @swc/core refuses a binding built for a different version, so the two specifiers must move in lockstep. Dependabot's dev-dependencies group happens to move both today — chore(deps): Bump the dev-dependencies group with 4 updates #1451 carries 1.16.13 -> 1.16.18 for each — but grouping is a cadence convenience, not a guarantee. An ungrouped security bump of @swc/core, or a local npm run update:pkgs, moves one and leaves the other, and the resulting version-mismatch at load looks nothing like a dependency edit.

   This is the same class the repository already writes contract tests for: a one-token change to something no test reads (tests/e2e-coverage-gate.test.mjs, tests/data-gate-contract.test.mjs, tests/refresh-script-wiring.test.mjs).

   Recommendation

   Add tests/swc-native-binding-contract.test.mjs, pinning the three properties such an edit would break, read from package.json and package-lock.json rather than from a registry:

   • @swc/core-linux-x64-gnu is declared as a devDependency, at an exact version (no range), equal to @swc/core's.
   • The lockfile entry node_modules/@swc/core-linux-x64-gnu is not marked optional: true (the marker [BUG] Platform-specific optional dependencies not being included in package-lock.json when reinstalling with node_modules present npm/cli#4828 acts on; npm's devOptional: true here is the expected, non-skippable state), is at the pinned version, and the lockfile's root devDependencies record agrees.
   • Fixture cases prove each check actually goes red on the edit it exists to catch, per the repository's "a guard nobody has seen go red is indistinguishable from one that always passes" convention.

   Raising both versions in lockstep keeps the guard green — verified against #1451's head (1.16.18/1.16.18, lock not optional).

   Scope is deliberately linux-x64-gnu only: every job in .github/workflows declares runs-on: ubuntu-24.04. Other platforms stay optional so contributors on macOS or arm64 are not forced to install a linux binary.

   Verification performed

   At eff33b5, node v26.10.0, TZ=UTC:

   • node --test tests/swc-native-binding-contract.test.mjs → 12 pass, 0 fail.
   • npm run test:unit:coverage:check (the exact gate the required Validate repository job runs) → exit 0; src files 100.00% lines / 100.00% regions unchanged, new file 100.00%/100.00%, and aggregate region coverage rises 96.13% → 96.15%.
   • npx prettier --check on the new file → clean.

   No change to package.json or package-lock.json — this issue adds a guard over the state #1428 already established, and does not relitigate it.

   Priority

   • Impact: high — the unguarded invariant is the only repository-side defence against an incident that has already failed main's deploy and all four CI jobs on a PR.
   • Effort: low — one new test file, no production or manifest change.

   ---

   🐝 Hive Agent: quality | Instance: hosted-available-lke648397-260827-5n31 | SHA: eff33b5

   — hive: agent=quality backend=copilot model=claude-opus-5 copilot=1.0.88
6. hivecommons-hive commented on Oct 14, 2026

   

   hivecommons-hiveBot

   on Oct 14, 2026 – with hivecommons-hive

   ContributorAuthor

   More actions

   Folded finding. This was filed as a separate issue, but 3 open agent-filed issues already cite ci.yml, so it was folded into the oldest of them instead of opening another. Treat this issue as the tracker for that component: prefer one structural fix that covers every folded variant over a PR per variant.

   [quality] unit coverage gate's measurement record is stale and contradicts the residual note it cites

   Finding

   tests/coverage-gate-thresholds.test.mjs is the unit lane's counterpart to
   tests/e2e-coverage-gate.test.mjs: it pins the --check* flags in
   package.json's test:unit:coverage:check to the coverage the suite already
   achieves, and carries a prose record of the measurement those floors were
   argued from. That record has gone stale, and one clause of it now contradicts
   the file it cites.

   Measured at main eff33b5 with TZ=UTC node tests/tools/coverage-report.mjs,
   twice — on node v22.23.3 (the major ci.yml pins) and on node v26.10.0 —
   with both runs agreeing to the region:

   row	recorded in the file	measured at eff33b5
   all files	99.65% lines / 96.14% regions (58948/59153 lines, 9515/9897 regions)	99.67% lines / 96.14% regions (65628/65843 lines, 10511/10933 regions)
   src files	100.00% / 100.00% (9233/9233 lines, 2777/2777 regions)	100.00% / 100.00% (9650/9650 lines, 2792/2792 regions)
   harness files	100.00% lines / 99.63% regions (5352/5352 lines, 1870/1877 regions)	100.00% lines / 99.64% regions (5717/5717 lines, 1947/1954 regions)

   The node version the record names as "the major ci.yml pins" is v22.21.1;
   22.23.3 is the current 22.x, and it is also the version
   tests/e2e-coverage-gate.test.mjs already cites in its own table.

   No floor moves. Every threshold in FLOORS still clears its measurement
   (99 ≤ 99.67, 96 ≤ 96.14, 99 ≤ 99.64, 98 ≤ 98.57, and the four 100s are
   exact), and npm run test:unit:coverage:check exits 0 at eff33b5. This is a
   record that no longer describes the suite, not a gate that has slipped.

   The contradiction

   The comment above --check-harness-file-regions says:

   98.57% is e2e-coverage-report.mjs's ceiling, not a backlog: its 6
   uncovered regions are the defensive fallbacks the note at the top of the file
   lists as unreachable (#1253 …)

   The note it points at, tests/tools/e2e-coverage-report.mjs:60-61, says:

   Together they are 7 regions, which caps this file at 98.57% regions;
   tests/coverage-gate-thresholds.test.mjs records that ceiling beside
   --check-harness-file-regions so the floor is never set above it.

   Seven is correct: the harness row measures 1947/1954, and the per-file row for
   tests/tools/e2e-coverage-report.mjs lists six lines (243, 634, 803, 814,
   1038, 1117) carrying seven regions — line 243's map.resolvedSources ?? flattened.sources ?? [] is the two-region chain the note describes.

   That matters beyond the digit. The note hands this file a job — "records that
   ceiling … so the floor is never set above it" — and nothing executes it. The
   relationship between the floor and the ceiling is prose on both sides, which is
   exactly the drift-by-omission class tests/docs-threshold-parity.test.mjs
   closes between the gate and the contributor docs, and
   tests/audit-gate.test.mjs closes between the allowlist and SECURITY.md. The
   stale 6 is the first instance of it landing here, and it landed silently.

   Recommendation

   One change to one file, tests/coverage-gate-thresholds.test.mjs:

   • Refresh the three measured rows and the node versions to the numbers
     above, and update --check's "next whole percent (99.65)" aside to
     99.67.
   • Stop restating the residual count in prose. Read the count and the
     ceiling back out of tests/tools/e2e-coverage-report.mjs's note and
     assert --check-harness-file-regions <= Math.floor(ceiling), so the
     sentence the floor is argued from can no longer drift from the floor —
     and so a rewrite that deletes the note fails here by name instead of
     leaving the floor with nothing behind it.

   Both halves belong in one commit: the refreshed counts are only trustworthy
   once something re-derives the one number that had already gone wrong.

   Priority

   • Impact: medium — no gate is loose today, but the record is the only argument
     for why --check-harness-file-regions stops at 98, and a contributor
     reconciling "6 unreachable regions" against a 1947/1954 harness row has
     nothing that tells them which number to trust.
   • Effort: low — comment refresh plus one assertion; no floor changes, no
     production code.

   ---

   🐝 Hive Agent: quality | Instance: hosted-available-lke648397-260827-5n31 | SHA: eff33b5

   — hive: agent=quality backend=copilot model=claude-opus-5 copilot=1.0.88
7. hivecommons-hive commented on Oct 14, 2026

   

   hivecommons-hiveBot

   on Oct 14, 2026 – with hivecommons-hive

   ContributorAuthor

   More actions

   A merged PR referenced this issue without closing it. Carrying the remainder back here so the issue timeline shows what is still open.

   • test: pin the unit gate's harness ceiling to the note it rests on #1463 — test: pin the unit gate's harness ceiling to the note it rests on (test: pin the unit gate's harness ceiling to the note it rests on #1463) — needs human

   Remainder from the PR body:

   #1411's own subject — a stale Test workflow
   registration, which is repo Actions state and not a file — cannot be fixed by
   any PR

   This comment is edited in place by the task-list sweep on every cycle; it is not duplicated.
8. hivecommons-hive

   added

   needs-human

   on Oct 14, 2026
9. mrbobbytables commented on Oct 14, 2026

   

   mrbobbytables

   on Oct 14, 2026

   Member

   More actions

   Disabled the orphaned registration as recommended:

   $ gh api -X PUT repos/cncf/endusers/actions/workflows/330065644/disable
   $ gh api repos/cncf/endusers/actions/workflows/330065644 --jq .state
   disabled_manually
   
10. mrbobbytables

    closed this as completedon Oct 14, 2026