The undo/redo test was timing-sensitive: it relied on the render loop's
1.5s snapshot debounce firing within the test's 3s time.sleep() between
set_value calls. In a shared live_gui subprocess (xdist batch), the
render loop runs much slower than the 60fps target because other tests'
API calls contend for the main thread.
The flaky failure mode: undo applied the wrong snapshot (or no
snapshot was pushed yet), so ai_input stayed at "Modified Input"
instead of reverting to "Initial Input".
Bumped the waits:
- After set_value: 3s -> 8s (covers render loop delay in batch)
- After undo/redo: 2s -> 4s (covers the apply-snapshot return path)
The test still verifies the same functionality (undo restores state,
redo re-applies it), just gives the render loop enough wall-clock
budget in batch context. The waits are still well below any test
timeout.
Verified: 3/3 undo/redo tests PASS in 49.46s isolated.
Files changed:
- tests/test_undo_redo_sim.py: bumped sleeps in test_undo_redo_lifecycle
ed