• Adds X server readiness check before launching fluxbox
• Installs x11-utils package for xdpyinfo availability
• Implements retry loop with 30 attempts and 0.5s intervals
• Eliminates race condition causing flaky window manager tests

Add X server readiness check before fluxbox startup

• Adds x11-utils package installation alongside fluxbox
• Implements polling loop using xdpyinfo to verify X server availability
• Waits up to 15 seconds (30 attempts × 0.5s) before starting fluxbox
• Prevents race condition where fluxbox starts before Xvfb is ready

.github/workflows/bazel.yml

Description

The workflow’s X server readiness wait loop can time out without failing, so the step still proceeds
to start fluxbox (backgrounded) even when xdpyinfo never succeeds and no display is actually
available. This violates the requirement to validate preconditions and to have deterministic timeout
failure paths for async waits, and can preserve the same intermittent/silent failure mode the wait
was meant to eliminate.

Code

.github/workflows/bazel.yml[R176-181]

+          # X server must start before fluxbox
+          for _ in $(seq 1 30); do
+            xdpyinfo -display :99 >/dev/null 2>&1 && break
+            sleep 0.5
+          done
          fluxbox -display :99 &

Evidence

PR Compliance ID 10 requires CI scripts to validate preconditions and fail safe, but the script does
not verify that the display became available after the polling loop completes. PR Compliance ID 12
requires deterministic timeout failure paths for async waits; here, the loop may end via timeout
without error, and fluxbox -display :99 & runs unconditionally afterward, meaning the step can
continue even if Xvfb never became ready, with failures easy to miss due to backgrounding.

.github/workflows/bazel.yml[176-181]
.github/workflows/bazel.yml[171-182]
Best Practice: Learned patterns
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The X server (Xvfb) readiness polling loop does not have a deterministic failure path: if `xdpyinfo` never succeeds within the timeout, the workflow still starts `fluxbox` in the background and continues, allowing silent/intermittent failures when no display is actually ready.

## Issue Context
This step is intended to eliminate a race where `fluxbox` starts before Xvfb is ready. CI/workflow scripts must validate preconditions and fail safe on errors, and async waits must have explicit timeouts with actionable failure when the timeout is exceeded; without a post-loop assertion, the race is only reduced, not eliminated.

## Fix Focus Areas
- .github/workflows/bazel.yml[171-182]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools