Skip to content

test(e2e): a swept stimulus has no fixed position to compare against - #132

Merged
joschaschmiedt merged 1 commit into
mainfrom
fix/e2e-moving-stimulus-compare
Aug 18, 2026
Merged

test(e2e): a swept stimulus has no fixed position to compare against#132
joschaschmiedt merged 1 commit into
mainfrom
fix/e2e-moving-stimulus-compare

Conversation

@joschaschmiedt

Copy link
Copy Markdown
Contributor

Two flakes left in the real-renderer suite after #130. Both were found by running make test-e2e on repeat locally; CI runs only the null renderer and sees neither.

The demo comparison compared a moving number

_canonical() already drops the runtime state a tutorial script cannot be held responsible for reproducing — enabled for a stimulus an animation owns, phase_cycles for a drifting grating. Position was missing from that list.

moving_target arms a MoveAlongSegments2D with FinalAction::RESTART, so it sweeps forever. By the time the test retrieves the config, the target has travelled some way along its path — how far depending on how many frames elapsed between the script exiting and the retrieve. Under the null renderer the gap is usually short enough to land on the start point; under a real 60 Hz display it often is not.

It now drops pos_px for any stimulus driven by an animation that writes position every frame (MoveAlongPath2D, MoveAlongSegments2D, ExternalPosition2D) — the same rule already applied to the other two runtime values.

The teardown could still fail the last test

#130 escalated a slow exit to SIGKILL, but kept a five-second reap after it. On a busy machine even that outran, and the TimeoutExpired landed on whichever test ran last (test_textbox2_colors). SIGKILL is not negotiable, so a process still present is stuck in the kernel handing the display back — the teardown now warns instead of turning cleanup time into a result about the code under test.

Verification

Real renderer (X11, GTX 1650): 141 passed, 6 xfailed, twice in a row; the demo group 3/3 on repeat. Null renderer: 141 passed, 6 xfailed. Test-suite only — no server or client code touched.

🤖 Generated with Claude Code

Two flakes left in the real-renderer suite after #130, both found by running it
on repeat.

**The demo comparison compared a moving number.** `_canonical` already drops the
runtime state a tutorial cannot be held responsible for — `enabled` for a
stimulus an animation owns, `phase_cycles` for a drifting grating — but not the
position of a stimulus a sweep is moving. `moving_target` arms a
MoveAlongSegments2D that runs forever, so by the time the test retrieves the
config the target has travelled some way along its path, and how far depends on
how many frames passed. It drops `pos_px` for any stimulus driven by an
animation that writes position every frame.

**The teardown could still fail the last test.** #130 escalated a slow exit to
SIGKILL; on a busy machine even the post-kill reap outran its five seconds, and
the error landed on whichever test happened to run last. SIGKILL is not
negotiable, so a process still there is stuck in the kernel handing the display
back: the teardown now says so with a warning instead of turning cleanup time
into a test result.

Real renderer: 141 passed, 6 xfailed, twice in a row, and the demo group 3/3 on
repeat. Null unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@joschaschmiedt
joschaschmiedt merged commit 512c640 into main Aug 18, 2026
6 checks passed
@joschaschmiedt
joschaschmiedt deleted the fix/e2e-moving-stimulus-compare branch August 18, 2026 11:21
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