Skip to content

[ZEPPELIN-1836] Make testAngularRunParagraph wait for rendered Angular output#5250

Draft
jongyoul wants to merge 1 commit into
apache:masterfrom
jongyoul:ZEPPELIN-selenium-angular-paragraph
Draft

[ZEPPELIN-1836] Make testAngularRunParagraph wait for rendered Angular output#5250
jongyoul wants to merge 1 commit into
apache:masterfrom
jongyoul:ZEPPELIN-selenium-angular-paragraph

Conversation

@jongyoul
Copy link
Copy Markdown
Member

What is this PR for?

testAngularRunParagraph has been failing on every frontend.yml test-selenium-with-spark-module-for-spark-3-5 run on master since the last green build at 6353224 on 2026-04-23. The failure is always at ZeppelinIT.java:348:

org.openqa.selenium.TimeoutException: Expected condition failed: waiting for visibility of element located by By.xpath: (//div[@ng-controller="ParagraphCtrl"])[1]//div[@id="angularRunParagraph"] (tried for 30 second(s) with 500 milliseconds interval)

Tracing the server log confirms the angular paragraph re-run completes successfully on the server side (paragraph FINISHED, result broadcast) and the stalenessOf(oldAngularDiv) check before visibilityWait does succeed — so the old angularRunParagraph div is detached as expected. The new div, however, is not detected as visible within 30s.

The race lives on the frontend side of the re-render: AngularJS' renderAngular() does elem.html(generated) and then $compile(elem.contents())(paragraphScope). Between those two calls the result div can be momentarily detached or empty, which is exactly the window visibilityWait polls into. Once it gets a stale reference, the wait does not refetch.

This builds on the stalenessOf + JavaScript-click fix from ZEPPELIN-6409 (#5209). That fix proved the old output was being torn down; this PR makes the wait for the new output equally tolerant of mid-$compile DOM churn.

What type of PR is it?

Bug Fix

Todos

  • Replace single visibilityWait with a content-aware polling wait that re-finds the element and ignores StaleElementReferenceException
  • Mirror the content-based pattern already used after the first run (waitForText(\"Run second paragraph\", ...))

What is the Jira issue?

How should this be tested?

  • CI frontend.ymltest-selenium-with-spark-module-for-spark-3-5 should run ZeppelinIT.testAngularRunParagraph to completion without timing out at line 348.
  • Local repro (slow, requires -Pweb-classic and Spark 3.5):
    ./mvnw verify -DfailIfNoTests=false -pl zeppelin-integration \
      -Pweb-classic -Pintegration -Pspark-scala-2.12 -Pspark-3.5 -Pweb-dist -Pusing-source-tree \
      -Dit.test=ZeppelinIT#testAngularRunParagraph
    

Screenshots (if appropriate)

N/A

Questions:

  • Does the license files need to update? No
  • Is there breaking changes for older versions? No
  • Does this needs documentation? No

…r output

After the rerun, visibilityWait alone races against AngularJS $compile —
the result div can briefly detach or render empty before settling, so the
wait times out at 30s on master frontend.yml runs.

Replace the single visibilityWait with a polling lambda that re-finds the
element each iteration, tolerates StaleElementReferenceException, and only
returns once the div is displayed *and* shows the expected text. This
mirrors the content-based pattern already used after the first run.

Builds on the stalenessOf + JS click fix from ZEPPELIN-6409.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant