Flaky `test_flight_animation_export_gif`: intermittent bus error in VTK off-screen rendering

[thc1006]

What happens

tests/integration/test_plots.py::test_flight_animation_export_gif, and the other VTK/PyVista off-screen animation tests near it, sometimes crash the whole pytest process:

Fatal Python error: Bus error
  File ".../tests/integration/test_plots.py", line 79 in test_flight_animation_export_gif

It is intermittent. The same commit and the same environment can pass one run and crash the next. When it does crash, the interpreter dies rather than a test failing cleanly, so the coverage upload is skipped and the whole matrix goes red.

Why it looks like a flake rather than a code regression

• It also hit develop's own Tests run on 2026-07-19 (https://github.com/RocketPy-Team/RocketPy/actions/runs/29697106388), at the same file and line.
• On a branch I was working on, a passing run and a crashing run installed the same rendering stack (vtk 9.6.2, pyvista 0.48.4, matplotlib 3.11.1, pillow 12.3.0), so it is not tied to a dependency bump.
• A bus error here is a native crash inside VTK's off-screen OpenGL, which tends to be a fragile spot on headless CI runners rather than something in the Python test logic.

Possible directions

• Retry only the animation tests, for example with pytest-rerunfailures (@pytest.mark.flaky(reruns=2)), so an occasional OpenGL hiccup does not take down the whole matrix.
• Or run the rendering tests in their own step or subprocess, so a crash there does not end the rest of the suite.
• Or, if it can be pinned down, look at the off-screen GL setup on the runners (software rendering / mesa).

I ran into this while working on #1054, which is a seeding change that does not touch plotting. Happy to send a small PR marking the animation tests with a rerun if that is the approach you would prefer.

[Gui-FernandesBR]

@thc1006 which branch and commit were you working at?

[thc1006]

Thanks for picking this up, @Gui-FernandesBR.

I was on my PR #1054, branch enh/reproducible-montecarlo-seeding, at commit da2ba5cf. The useful part is that it is not specific to my branch: the same crash happens on develop. The Tests run on develop d31822d3 failed the same way.

Both crash in the Pytest (macos-latest, 3.14) job, during pytest tests/integration:

Fatal Python error: Bus error
  File ".../tests/integration/test_plots.py", line 79 in test_flight_animation_export_gif
... Bus error: 10   pytest tests/integration --cov=rocketpy --cov-append

• develop d31822d3: run 29697106388, the Pytest (macos-latest, 3.14) job
• my ENH: reproducible Monte Carlo via per-simulation-index seeding #1054 da2ba5cf: run 29728954730, the same job

A few things point to a flake rather than a real failure:

• The other matrix jobs in each run show The operation was canceled, not a test failure. That is fail-fast cancelling the siblings once the macOS job dies (it leaves orphan pytest and Xvfb processes behind), so a run can look like every job failed when only macos-3.14 actually crashed.
• It is intermittent on the same code: an earlier commit of mine, e5ba9404, passed Pytest (macos-latest, 3.14), and da2ba5cf crashed it.
• Same rendering stack in the passing and crashing runs: vtk 9.6.2, pyvista 0.48.4, matplotlib 3.11.1, pillow 12.3.0, so it is not a version bump.
• My change only touches Monte Carlo seeding, nothing in the plotting path.

So it reads as a native crash in the VTK off-screen GIF export on the macOS runner. Happy to send a small PR marking the animation tests with a rerun (e.g. pytest-rerunfailures) if that is the direction you would prefer.

[wuisabel-gif]

Picking this up (thanks @thc1006). One wrinkle worth flagging before choosing the approach:

• rerun alone won't catch it. A Bus error is a native SIGBUS that kills the interpreter, so pytest-rerunfailures has nothing left to rerun — the process is already gone.
• fork isolation is out on this matrix. pytest-forked would contain the crash, but it needs os.fork, and the test matrix includes windows-latest.

So I'd go at the root cause instead. The crash is VTK's off-screen OpenGL on the headless Linux runner (the setup-headless-display-action gives a display, but the GL path is still the fragile bit). Forcing Mesa software rendering removes exactly this class of intermittent bus error and keeps the tests running (no coverage loss, no new deps, no per-test markers):

env:
  LIBGL_ALWAYS_SOFTWARE: "1"
  GALLIUM_DRIVER: llvmpipe

It's a no-op on the macOS/Windows legs (no Mesa), so it's matrix-safe. I'll open a small PR adding that to test_pytest.yaml and test-pytest-slow.yaml. If it turns out to still flake after that, the clean fallback is a rerun layer for residual soft failures — but software rendering should take out the hard crash. Happy to go a different direction (separate CI step, skip) if a maintainer prefers.