Fix WildFly scheduled test race - #12385
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
More details
The new loop waits while the request is pending. It stops after the EJB clears the flag.
🤖 Datadog Autotest · Commit 076e262 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
ygree
left a comment
There was a problem hiding this comment.
Good catch! Perhaps ENABLED is to a clear name for this flag.
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
c6a78ec
into
master
What Does This Do
Corrects the WildFly scheduled-EJB smoke-test handshake. The
/enableSchedulingcontroller now waits while the scheduled request remains pending and returns after the EJB consumes the flag.Motivation
The previous wait condition was inverted. When the scheduled EJB reset
ENABLEDbefore the asynchronous supplier read it, the supplier entered a loop that could not end and Spring eventually returned HTTP 503 instead of 200. The test passed when the supplier happened to run first because it observedtrue, skipped the inverted loop, and returned immediately.Additional Notes
Failure evidence: affected executions spent about 30.5 seconds in
scheduled ejb has right service nameand then failedresponse.code() == 200because the response code was 503. That duration is consistent with the Spring asynchronous request timeout.The flag states are:
true: a scheduled invocation is pending.false: the scheduled EJB has picked up the request withgetAndSet(false).Changing the loop from
while (!ENABLED.get())towhile (ENABLED.get())makes both thread orderings safe. If the supplier runs first, it waits for the EJB to clear the flag. If the EJB runs first, the supplier observesfalseand returns immediately.AtomicBooleanprovides visibility between the two threads.The EJB clears the flag before calling
generateSomeTrace(), so HTTP 200 specifically confirms that the EJB picked up the request. The suite-level trace-count assertion independently verifies that the scheduled trace was emitted.Validation:
./gradlew :dd-smoke-tests:wildfly:test -PtestJvm=8— 203 tests passed../gradlew :dd-smoke-tests:wildfly:test -PtestJvm=11— 203 tests passed../gradlew :dd-smoke-tests:wildfly:test -PtestJvm=8 --rerun-tasks— 203 tests passed.Relevant precedent: #8064 introduced this scheduled-EJB service-name coverage and its flag handshake.
Contributor Checklist
type:and (comp:orinst:) labels in addition to any other useful labelsclose,fix, or any linking keywords when referencing an issueUse
solvesinstead, and assign the PR milestone to the issueJira ticket: N/A