tests: thread stress tests intermittent failures under QEMU (stress_aes, stress_recurse, stress_schedule)
Three thread stress tests fail intermittently under QEMU emulation on CI:
thread/stress_aes.py — times out on QEMU ARM/MIPS/RISCV64. Execution
time approaches or exceeds the configured timeout (70-180s depending on
arch). Observed 7 times in a 20-run log window. Attributed to ~28 of 103
failed runs over 14 months. On RISCV64 it's excluded entirely because it
takes ~180s against a 200s timeout.
thread/stress_recurse.py — was already excluded from qemu_mips,
qemu_arm, qemu_riscv64 with "is flaky" comments. No direct log
observations in the sample window since it was excluded, but the
exclusion predates the analysis period.
thread/stress_schedule.py — crashed once (expected PASS, got
CRASH) on qemu_riscv64 in the 20-run window. Low frequency but a
crash rather than a timeout suggests a real issue.
These may be QEMU-specific timing/emulation issues rather than bugs in
MicroPython's threading, but the crash in stress_schedule suggests at
least some of these are real.
PR #18861 now ignores these failures in CI. stress_aes.py is additionally
excluded on RISCV64 to avoid burning ~180s of CI time on each timeout.
See analysis: https://gist.github.com/andrewleech/5686ed5242e0948d8679c432579e002e
tests: thread/stress_heap.py intermittent failure on macOS
The stress_heap.py test was excluded from the macOS CI job with a "is
flaky" comment prior to the analysis period. No direct log observations
are available since it was already excluded, but it's listed in
FLAKY_TESTS restricted to the darwin platform.
PR #18861 now handles this via ignore-on-failure instead of exclusion,
so the test runs and its output is visible but doesn't block CI.
See analysis: https://gist.github.com/andrewleech/5686ed5242e0948d8679c432579e002e