bstein/bstein-dev-home
1
0
Fork 0
Code Issues 27 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

[hermes] bstein-dev-home #473: frontend_e2e_overlay_assertion_failure #24

New Issue
Open
opened 2026-08-18 10:00:43 +00:00 by hermes-automation · 0 comments
hermes-automation commented 2026-08-18 10:00:43 +00:00
Copy Link

Hermes auto-triage classified incident bstein-dev-home/473 as frontend_e2e_overlay_assertion_failure (confidence 0.83); first failed gate: Enforce quality gate (frontend end-to-end tests).

Why a human is needed

Build 473 failed because of one frontend end-to-end test, not an infrastructure problem. In testing/frontend/e2e/home.spec.js the test at line 76, "shows Brad's professional homepage and opens the platform diagram overlay", clicks .diagram inside the first card (line 102) and then asserts that locator('.overlay') becomes visible. Playwright waited 10s for that locator, never matched any element ("Received: undefined"), and the test then hit its 60s timeout. Everything before that point worked: the first card was found and visible, and the click itself did not error. The backend suite in the same build passed 128/128, so the fault is confined to the homepage overlay interaction. Fixing this means opening the homepage component and checking three things: whether the overlay element is still rendered with the class name overlay (a rename, or a CSS-module/scoped-class change that produces a hashed class, would break this selector even though the feature still works); whether the click handler on .diagram is still wired up and still sets the state that mounts the overlay; and whether the overlay now mounts only after an async fetch that has no data or no backing service in CI, in which case it never appears there even though it appears locally. If the markup deliberately changed, update the locator in the spec (a stable data-testid on the overlay root would prevent this class of breakage recurring). If the markup did not change, the overlay-open path has regressed and the component is what needs fixing. A maintainer needs to make that call, because this evidence contains no repository source and no Playwright trace, screenshot, or frontend JUnit XML that would show which side moved; running the spec locally with a trace, or enabling trace/screenshot retention on failure in the Playwright config, will settle it in one run. One unrelated issue is worth fixing while you are in here: the SonarQube scan could not launch Node ("Cannot run program "node": error=2, No such file or directory"), so JavaScript and TypeScript analysis produced no results in this build and will keep producing none until Node is available on PATH in the scanner container. That did not fail this build.

Ariadne did not authorize automated remediation: human_required.

Facts

  • jenkins — Build 473 of job bstein-dev-home finished with result FAILURE at 2026-08-18T09:57:21Z after 1880.9s. (jenkins.result / jenkins.timestamps / https://ci.bstein.dev/job/bstein-dev-home/473/)
  • jenkins — Jenkins reported the first failed stage as "Enforce quality gate". (jenkins.first_failed_stage)
  • jenkins — The build published no structured test results: jenkins.failed_tests is an empty array. (jenkins.failed_tests)
  • jenkins — The backend suite passed: "128 passed in 34.76s", JUnit XML written to build/junit-backend.xml, and the shell recorded backend_rc=0. (jenkins.console_failures[2] (line 690))
  • jenkins — The Playwright spec ../testing/frontend/e2e/home.spec.js:76:5 "shows Brad's professional homepage and opens the platform diagram overlay" failed with "Test timeout of 60000ms exceeded" and "expect(locator).toBeVisible() failed / Locator: locator('.overlay') / Expected: visible / Received: undefin... (jenkins.console_failures[3] (line 898))
  • jenkins — The excerpt shows the test steps immediately before the failing assertion: line 101 "await expect(firstCard).toBeVisible();" and line 102 "await firstCard.locator(".diagram").click();". (jenkins.console_failures[3] (line 898))
  • jenkins — During the SonarQube scan the JavaScript sensor could not start Node: "Error when running: 'node -v'. Is Node.js available during analysis?" and "Caused by: java.io.IOException: Cannot run program "node": error=2, No such file or directory"; the scan continued and the TypeScript sensor complete... (jenkins.console_failures[0] (line 329) and jenkins.console_failures[1] (line 365))
  • jenkins — The end of the build shows "Stage "Build & push backend" skipped due to earlier failure(s)", "ERROR: script returned exit code 1" and "Finished: FAILURE". (jenkins.console_tail)
  • opensearch — No correlated log records were returned for the window 2026-08-18T09:21:00Z to 2026-08-18T10:02:21Z (records empty, no query error). (log_evidence.records / log_evidence.query_window)

Evidence

The earliest failure region of the build console:

09:32:50.412 INFO  Sensor JaCoCo XML Report Importer [jacoco] (done) | time=32ms
09:32:50.421 INFO  Sensor IaC CloudFormation Sensor [iac]
09:32:51.989 INFO  0 source files to be analyzed
09:32:52.500 INFO  0/0 source files have been analyzed
09:32:52.500 INFO  Sensor IaC CloudFormation Sensor [iac] (done) | time=2080ms
09:32:52.501 INFO  Sensor IaC Kubernetes Sensor [iac]
09:32:53.009 INFO  0 source files to be analyzed
09:32:54.036 INFO  0/0 source files have been analyzed
09:32:54.038 INFO  Sensor IaC Kubernetes Sensor [iac] (done) | time=1536ms
09:32:54.039 INFO  Sensor JavaScript analysis [javascript]
09:33:27.637 ERROR Error when running: 'node -v'. Is Node.js available during analysis?
org.sonarsource.nodejs.NodeCommandException: Error when running: 'node -v'. Is Node.js available during analysis?
	at org.sonarsource.nodejs.NodeCommand.start(NodeCommand.java:79)
	at org.sonarsource.nodejs.NodeCommandBuilderImpl.getVersion(NodeCommandBuilderImpl.java:203)
	at org.sonarsource.nodejs.NodeCommandBuilderImpl.checkNodeCompatibility(NodeCommandBuilderImpl.java:169)
	at org.sonarsource.nodejs.NodeCommandBuilderImpl.build(NodeCommandBuilderImpl.java:143)
	at org.sonar.plugins.javascr
... (truncated; the full log is in the linked build)

Inferences

  • The enforced failure is the frontend end-to-end test. The backend stage captured its exit status into a variable instead of failing immediately (the console shows backend_rc=0 being written out), so the pipeline defers enforcement to a later stage; that is why Jenkins names "Enforce quality gate"...
  • "Received: undefined" together with the call log "waiting for locator('.overlay')" means no element matching .overlay was ever present in the DOM during the wait, rather than an element being present but hidden or covered. The overlay either was never mounted after the .diagram click, or it is no...
  • The interaction up to the click succeeded (the first card was visible and the .diagram click did not error), so the regression is in what happens after the click, not in page load or card rendering.
  • Because the test spends the full 60s and the assertion waits 10s, this looks like a deterministic "overlay never opens" condition rather than a slow render; a timing-only flake would usually resolve within the 10s expect window.
  • The missing Node binary in the scanner environment means JavaScript and TypeScript analysis contributed nothing to this SonarQube run. That did not fail the build, but the JS/TS quality signal for this repository is currently blank and would stay blank on every build until Node is on PATH in the ...
  • The backend is unaffected (128/128 passing), so the blast radius is the homepage diagram-overlay code path in the frontend and anything gated on the e2e suite.

Links

Filed automatically by Ariadne from a Hermes Agent diagnosis (run [run_a4d977124036443b88d9

Truncated by Ariadne: the diagnosis exceeded the configured issue body limit. The complete evidence bundle is in the Ariadne audit trail.

Hermes auto-triage classified incident `bstein-dev-home/473` as **frontend_e2e_overlay_assertion_failure** (confidence 0.83); first failed gate: `Enforce quality gate (frontend end-to-end tests)`. ## Why a human is needed Build 473 failed because of one frontend end-to-end test, not an infrastructure problem. In testing/frontend/e2e/home.spec.js the test at line 76, "shows Brad's professional homepage and opens the platform diagram overlay", clicks .diagram inside the first card (line 102) and then asserts that locator('.overlay') becomes visible. Playwright waited 10s for that locator, never matched any element ("Received: undefined"), and the test then hit its 60s timeout. Everything before that point worked: the first card was found and visible, and the click itself did not error. The backend suite in the same build passed 128/128, so the fault is confined to the homepage overlay interaction. Fixing this means opening the homepage component and checking three things: whether the overlay element is still rendered with the class name overlay (a rename, or a CSS-module/scoped-class change that produces a hashed class, would break this selector even though the feature still works); whether the click handler on .diagram is still wired up and still sets the state that mounts the overlay; and whether the overlay now mounts only after an async fetch that has no data or no backing service in CI, in which case it never appears there even though it appears locally. If the markup deliberately changed, update the locator in the spec (a stable data-testid on the overlay root would prevent this class of breakage recurring). If the markup did not change, the overlay-open path has regressed and the component is what needs fixing. A maintainer needs to make that call, because this evidence contains no repository source and no Playwright trace, screenshot, or frontend JUnit XML that would show which side moved; running the spec locally with a trace, or enabling trace/screenshot retention on failure in the Playwright config, will settle it in one run. One unrelated issue is worth fixing while you are in here: the SonarQube scan could not launch Node ("Cannot run program \"node\": error=2, No such file or directory"), so JavaScript and TypeScript analysis produced no results in this build and will keep producing none until Node is available on PATH in the scanner container. That did not fail this build. Ariadne did not authorize automated remediation: `human_required`. ## Facts - **jenkins** — Build 473 of job bstein-dev-home finished with result FAILURE at 2026-08-18T09:57:21Z after 1880.9s. (`jenkins.result / jenkins.timestamps / https://ci.bstein.dev/job/bstein-dev-home/473/`) - **jenkins** — Jenkins reported the first failed stage as "Enforce quality gate". (`jenkins.first_failed_stage`) - **jenkins** — The build published no structured test results: jenkins.failed_tests is an empty array. (`jenkins.failed_tests`) - **jenkins** — The backend suite passed: "128 passed in 34.76s", JUnit XML written to build/junit-backend.xml, and the shell recorded backend_rc=0. (`jenkins.console_failures[2] (line 690)`) - **jenkins** — The Playwright spec ../testing/frontend/e2e/home.spec.js:76:5 "shows Brad's professional homepage and opens the platform diagram overlay" failed with "Test timeout of 60000ms exceeded" and "expect(locator).toBeVisible() failed / Locator: locator('.overlay') / Expected: visible / Received: undefin... (`jenkins.console_failures[3] (line 898)`) - **jenkins** — The excerpt shows the test steps immediately before the failing assertion: line 101 "await expect(firstCard).toBeVisible();" and line 102 "await firstCard.locator(\".diagram\").click();". (`jenkins.console_failures[3] (line 898)`) - **jenkins** — During the SonarQube scan the JavaScript sensor could not start Node: "Error when running: 'node -v'. Is Node.js available during analysis?" and "Caused by: java.io.IOException: Cannot run program \"node\": error=2, No such file or directory"; the scan continued and the TypeScript sensor complete... (`jenkins.console_failures[0] (line 329) and jenkins.console_failures[1] (line 365)`) - **jenkins** — The end of the build shows "Stage \"Build & push backend\" skipped due to earlier failure(s)", "ERROR: script returned exit code 1" and "Finished: FAILURE". (`jenkins.console_tail`) - **opensearch** — No correlated log records were returned for the window 2026-08-18T09:21:00Z to 2026-08-18T10:02:21Z (records empty, no query error). (`log_evidence.records / log_evidence.query_window`) ## Evidence The earliest failure region of the build console: ``` 09:32:50.412 INFO Sensor JaCoCo XML Report Importer [jacoco] (done) | time=32ms 09:32:50.421 INFO Sensor IaC CloudFormation Sensor [iac] 09:32:51.989 INFO 0 source files to be analyzed 09:32:52.500 INFO 0/0 source files have been analyzed 09:32:52.500 INFO Sensor IaC CloudFormation Sensor [iac] (done) | time=2080ms 09:32:52.501 INFO Sensor IaC Kubernetes Sensor [iac] 09:32:53.009 INFO 0 source files to be analyzed 09:32:54.036 INFO 0/0 source files have been analyzed 09:32:54.038 INFO Sensor IaC Kubernetes Sensor [iac] (done) | time=1536ms 09:32:54.039 INFO Sensor JavaScript analysis [javascript] 09:33:27.637 ERROR Error when running: 'node -v'. Is Node.js available during analysis? org.sonarsource.nodejs.NodeCommandException: Error when running: 'node -v'. Is Node.js available during analysis? at org.sonarsource.nodejs.NodeCommand.start(NodeCommand.java:79) at org.sonarsource.nodejs.NodeCommandBuilderImpl.getVersion(NodeCommandBuilderImpl.java:203) at org.sonarsource.nodejs.NodeCommandBuilderImpl.checkNodeCompatibility(NodeCommandBuilderImpl.java:169) at org.sonarsource.nodejs.NodeCommandBuilderImpl.build(NodeCommandBuilderImpl.java:143) at org.sonar.plugins.javascr ... (truncated; the full log is in the linked build) ``` ## Inferences - The enforced failure is the frontend end-to-end test. The backend stage captured its exit status into a variable instead of failing immediately (the console shows backend_rc=0 being written out), so the pipeline defers enforcement to a later stage; that is why Jenkins names "Enforce quality gate"... - "Received: undefined" together with the call log "waiting for locator('.overlay')" means no element matching .overlay was ever present in the DOM during the wait, rather than an element being present but hidden or covered. The overlay either was never mounted after the .diagram click, or it is no... - The interaction up to the click succeeded (the first card was visible and the .diagram click did not error), so the regression is in what happens after the click, not in page load or card rendering. - Because the test spends the full 60s and the assertion waits 10s, this looks like a deterministic "overlay never opens" condition rather than a slow render; a timing-only flake would usually resolve within the 10s expect window. - The missing Node binary in the scanner environment means JavaScript and TypeScript analysis contributed nothing to this SonarQube run. That did not fail the build, but the JS/TS quality signal for this repository is currently blank and would stay blank on every build until Node is on PATH in the ... - The backend is unaffected (128/128 passing), so the blast radius is the homepage diagram-overlay code path in the frontend and anything gated on the e2e suite. ## Links - Failed build: https://ci.bstein.dev/job/bstein-dev-home/473/ - Full evidence bundle and audit trail live in Ariadne at `/api/admin/audit/events`, event types `hermes_autotriage_incident` and `hermes_autotriage_diagnosis`. Filed automatically by Ariadne from a Hermes Agent diagnosis (run [run_a4d977124036443b88d9 _Truncated by Ariadne: the diagnosis exceeded the configured issue body limit. The complete evidence bundle is in the Ariadne audit trail._ <!-- hermes-triage job=bstein-dev-home classification=frontend_e2e_overlay_assertion_failure incident=bstein-dev-home/473 -->
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
bstein
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: bstein/bstein-dev-home#24
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?