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

[quality] /resources/radar-reports e2e is smoke-depth only: a dropped report or a stripped rel=noreferrer ships green

Closed Beginner friendly
  • Is something wrong?
#833 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
84/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript, playwright
Domain
testing-qa, web-dev

Research direction

Create tests/e2e/radar-reports.spec.js, using tests/e2e/metrics-dashboard.spec.js as the model and data/radar-reports.json as the expected corpus. Run npx playwright test and verify the route renders every report in order with titles, dates, summaries, flat h3 headings, valid provenance, absolute HTTPS URLs, and noreferrer on every target="_blank" link.

Written by the indexing model from the issue text.

Description

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

Finding

/resources/radar-reports is the only route that renders
src/components/RadarReports. It has full unit coverage and it is reached by
the e2e suite — but only at smoke depth, and that depth cannot observe the two
regressions the page is actually exposed to.

tests/e2e/smoke.spec.js:81-93 is the sole spec that loads the route. It
asserts three things: the section is visible, it contains more than zero <li>,
and the first link is absolute.

tests/radar-reports.test.mjs and tests/radar-reports-fallbacks.test.mjs
report 100% line and branch coverage for the component, but they drive the JSX
through tests/tools/fake-dom.mjs against a synthetic corpus. They never render
the real data/radar-reports.json and never build a document outline, so they
cannot speak for the shipped page.

The corpus is rebuilt daily from cncf.io by npm run collect:radar-reports via
.github/workflows/refresh-radar-reports.yml, so the rendered content can
change — or shrink — with no source change at all.

Mutation evidence

Verified locally at 7772dcf (npm run build:production, then
npx playwright test, chromium). Two independent regressions were introduced
and the existing suite stayed green for both:

  1. A silently dropped report. Rendering
    (data.radarReports || []).slice(0, -1) publishes five of the six reports in
    the data file. smoke.spec.js passes: "more than zero <li>" is satisfied by
    five just as well as by six.
  2. Reverse tabnabbing. Deleting rel="noreferrer" from the report title
    anchor leaves every target="_blank" report link able to reach back through
    window.opener. smoke.spec.js passes: it only checks that the first link's
    href is absolute, never its rel.

The second is the notable one, because the repo already treats this as
load-bearing elsewhere: tests/e2e/footer.spec.js:99 and
tests/e2e/metrics-dashboard.spec.js:49-58 both assert rel=noreferrer against
the hydrated document. /resources/radar-reports is the remaining
external-link surface that does not.

Recommendation

Add tests/e2e/radar-reports.spec.js, modelled on the existing
tests/e2e/metrics-dashboard.spec.js (data-driven assertions against the JSON
corpus rather than against any particular published report):

  • assert one <li> per entry in data/radar-reports.json, and that the
    rendered title hrefs equal the corpus URLs in order (the collector
    writes newest-first and the component maps the array as-is)
  • assert each entry renders its title link, a date and its summary
  • assert the report headings are a flat set of <h3>
  • assert the provenance line credits data.sourceUrl and renders a real
    formatted date, catching an Invalid Date reaching the page
  • assert every target="_blank" link in the section carries
    rel=noreferrer
  • assert every report href is absolute https://

One caveat for whoever writes it: the component formats dates with
toLocaleDateString('en-US', ...), which resolves against the renderer's
timezone. A date-only string such as 2026-09-07 parses as UTC midnight, so a
build west of UTC legitimately renders "September 6, 2026" — confirmed in the
current build/ output. Assert the date shape, not the exact day, or the
suite encodes the build host's timezone.

Priority

  • Impact: medium
  • Effort: low

Filed by quality agent (hold-gated mode).

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

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

Dominant language
JavaScript
Stars
0
Forks
2
Avg merge
18h 33m
Merged PRs (30d)
527

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.