Repository navigation
YARN-12006. Wait for the first attempt in TestRouterWebServicesREST.getAppAttempt. - #8791
Merged
Merged
Conversation
…etAppAttempt. getAppAttempt read getAttempts().get(0) right after the submission returned, before the RM had created the first attempt, and threw IndexOutOfBoundsException. Wait up to 10s for the attempt, close the client, and give the two tests that call it a 30s timeout. Contains content generated by Claude Code. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3 of 6 tasks
|
🎊 +1 overall
This message was automatically generated. |
slfan1989
approved these changes
Oct 6, 2026
slfan1989
left a comment
Contributor
There was a problem hiding this comment.
Thanks for the fix.
Waiting for the first attempt is appropriate because application submission can return before the RM creates it. The increased test timeouts and client cleanup also look good.
I verified that the previous implementation fails on an empty attempt list, while this change succeeds once an attempt appears and fails after the timeout if the list remains empty.
CI is green.
LGTM, +1.
3 of 6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of PR
JIRA: https://issues.apache.org/jira/browse/YARN-12006
TestRouterWebServicesREST(andTestFederationWebApp, which extends it) fails intermittently intestGetAppAttemptXMLandtestGetContainersXMLwithIndexOutOfBoundsExceptioningetAppAttempt. The change is test-only.getAppAttemptreadgetAttempts().get(0)right after the submission returned, before the RM had created the first attempt. It now waits up to 10s for the attempt and closes the client it creates.testGetAppAttemptXMLandtestGetContainersXMLget a 30s timeout instead of 2s, because they now wait.Related: YARN-12004 (#8787) fixes the Router-vs-RM comparison races in the same class, which this PR does not address. The two PRs are independent and merge cleanly in either order.
How was this patch tested?
Locally on Linux with OpenJDK 21 and Maven 3.9.11, in
hadoop-yarn-server-router, on this PR's head:mvn test -Dtest=TestRouterWebServicesREST,TestFederationWebApp: 94 tests (42 + 52), 0IndexOutOfBoundsException.testGetAppAttemptXMLandtestGetContainersXMLlooped 300 times against one cluster in one JVM (600 runs), :getAppAttemptnever failed.For code changes:
declared according to the connector-specific documentation? Note: Automated CI
testing doesn't cover all cases so manual testing with cloud storage is still
required. N/A, no object storage changes.
LICENSE,LICENSE-binary,NOTICE-binaryfiles? N/AAI Tooling
If an AI tool was used:
where is the name of the AI tool used.
https://www.apache.org/legal/generative-tooling.html
Contains content generated by Claude Code.