Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[quality] e2e coverage failure reports say 'run null; status unknown' for every error raised after the manifest is read

Open Beginner friendly
#1,069 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@hivecommons-hive is already working on this.

Since Oct 5, 2026.

  • #1070 by @hivecommons-hive — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
github-actions, javascript, node.js
Domain
ci-cd, testing

Research direction

Start with the catch block in tests/tools/e2e-coverage-report.mjs and the CLI cases in tests/e2e-coverage-report.test.mjs; run npm run test:unit:coverage to see the existing coverage tests. Add cases for readable passed and failed manifests that trigger a plain Error, plus the absent or unreadable manifest case. Done means failure reports retain manifest runId/runStatus when available, preserve failed/cancelled status, and still use null fields when no manifest can be read.

Written by the indexing model from the issue text.

Description

agent/quality hive/covered-by-pr hive/hosted-available-lke648397-260827-5n31 quality testing

Finding

When tests/tools/e2e-coverage-report.mjs fails for any reason after the run
manifest has been read and validated, the failure report it publishes claims it
does not know which run it was rendering — even though it does.

main() builds its fallback report from fields that only CoverageReportError
carries (tests/tools/e2e-coverage-report.mjs:688-696):

    status:
      error.runStatus === 'failed' || error.runStatus === 'cancelled'
        ? error.runStatus
        : 'tooling-error',
    runId: error.runId ?? null,
    runStatus: error.runStatus ?? null,

Only four throw sites construct a CoverageReportError, and all four are the
run-status/capture guards near the top of collectE2ECoverage
(lines 461, 467, 484). Every later failure is a plain Error:

  • coverage run contains incomplete temporary artifacts (line 474)
  • unexpected coverage artifact kind in <entry> (line 490)
  • coverage artifact <entry> belongs to another run (line 493)
  • No src/** coverage was attributable (line 619)
  • every per-script conversion failure — source map escapes build directory
    (162, 166), generated source has no sourceMappingURL comment (178),
    generated source hash mismatch (369), and the map-resolution throws at
    211, 222, 229, 260, 344, 351, 361.

For all of those, error.runId and error.runStatus are undefined, so
renderE2ECoverageReport (line 626) emits:

E2E coverage: tooling-error (run null; status unknown)
Why it matters

.github/workflows/ci.yml:236-249 cats coverage/e2e/report.txt straight into
$GITHUB_STEP_SUMMARY, and that header line is the whole diagnostic. A reader
of a red End-to-end coverage job cannot tell from it whether

  • the Playwright run itself failed and the reporter is faithfully reporting a
    sealed-failed run, or
  • the Playwright run passed and only the reporting step broke.

Those two have opposite remedies, and the artifact erases the distinction at
exactly the moment it is needed. The same null lands in report.json, so
anything consuming the JSON inherits it.

There is a second, smaller consequence: a run sealed failed or cancelled
that then trips one of the plain-Error sites is reported with
status: 'tooling-error' rather than failed/cancelled, because the ternary
above also reads error.runStatus. The report blames the tooling for a test
failure.

Reproduction

At 900592b, render any sealed-passed run whose scripts cannot be attributed
to the local build/ — e.g. a published e2e-coverage artifact unpacked next
to a different build:

$ node tests/tools/e2e-coverage-run.mjs seal --dir "$RUN_DIR" --status passed
{"schemaVersion":1,...,"runId":"local1","status":"passed",...}

$ npm run report:e2e:coverage -- --input "$RUN_DIR" --build build --text out.txt
$ head -1 out.txt
E2E coverage: tooling-error (run null; status unknown)

The manifest on disk says "runId": "local1", "status": "passed". The report
says null / unknown.

Evidence and provenance
  • Unit: npm run test:unit:coverage (TZ=UTC node tests/tools/coverage-report.mjs,
    node v26.10.0), local, revision 900592b — tests/tools/e2e-coverage-report.mjs
    100.00% lines / 90.68% regions. The main() catch block is executed by the
    existing CLI tests, but no test asserts the runId/runStatus it writes for
    a non-CoverageReportError failure, which is why the defect is invisible to
    the suite.
  • Reproduced locally twice at 900592b as shown above, once against a freshly
    sealed local run and once against the e2e-coverage artifact of CI run
    37164361552.
  • This is a reporting-fidelity defect, not a coverage gap: no claim is made
    here about any source path's end-to-end coverage.

Recommendation

Fall back to the run manifest in main()'s catch, so the published failure
report names the run whenever the manifest is readable:

  } catch (error) {
    // Only the run-status guards raise CoverageReportError; every later
    // failure is a plain Error, so re-read the manifest rather than publish a
    // report that cannot say whether the run passed or the tooling broke.
    const run = await readCoverageRun(resolve(options.input)).catch(() => null);
    const runStatus = error.runStatus ?? run?.status ?? null;
    const failure = {
      schemaVersion: 2,
      kind: ERROR_KIND,
      status:
        runStatus === 'failed' || runStatus === 'cancelled'
          ? runStatus
          : 'tooling-error',
      runId: error.runId ?? run?.runId ?? null,
      runStatus,
      ...

readCoverageRun is already imported at line 14, and the .catch(() => null)
keeps an unreadable or absent manifest behaving exactly as it does today.

Cover it in tests/e2e-coverage-report.test.mjs with two CLI cases:

  1. a sealed-passed run that trips a plain-Error site, asserting the written
    report carries that runId and runStatus: 'passed' with
    status: 'tooling-error';
  2. a sealed-failed run that trips the same site, asserting status is
    'failed' rather than 'tooling-error'.

Coordination

The fix lands only in main() (tests/tools/e2e-coverage-report.mjs:674-713).

  • #1040 edits the same file at
    convertScript and inside collectE2ECoverage (script-root resolution); it
    does not touch main() or any throw site.
  • #1051 edits getRegionCoverage
    and the union; it does not touch main().

No open PR claims this function, so the change is disjoint from both.

Completion criteria

  • A failure report for a readable manifest carries the run's real runId and runStatus
  • A run sealed failed/cancelled is reported with that status, not tooling-error
  • An unreadable or absent manifest still yields runId: null / runStatus: null
  • tests/e2e-coverage-report.test.mjs covers all three

Priority

  • Impact: medium (CI's only published e2e diagnostic misattributes test failures to the tooling)
  • Effort: low

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

— hive: agent=quality backend=copilot model=claude-opus-5 copilot=1.0.88

Dominant language
JavaScript
Stars
0
Forks
2
Avg merge
22h 43m
Merged PRs (30d)
371

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cncf/endusers

All issues in cncf/endusers

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.