Bug report
test_sqlite_storage (fault_manager) intermittently times out under the Pixi (humble) CI job. The individual SqliteFaultStorageTest cases run in single-digit milliseconds each, so a 60 s timeout is a scheduling/resource stall under parallel test load, not a real hang. It passes on re-run.
Steps to reproduce
- Run the fault_manager test suite under the
Pixi (humble) CI job (or under heavy parallel load).
- Observe
test_sqlite_storage occasionally hit the 60 s CTest timeout.
Expected behavior
test_sqlite_storage completes well within its timeout (each case is a few ms).
Actual behavior
2/9 Test #2: test_sqlite_storage ..............***Timeout 60.00 sec
The following tests FAILED:
2 - test_sqlite_storage (Timeout)
Failing job: https://github.com/selfpatch/ros2_medkit/actions/runs/28042302548/job/83011418985
The same job passed on re-run (no code change), confirming the flake.
Environment
- ros2_medkit version: main
- ROS 2 distro: Humble (Pixi job)
- OS: Pixi/conda-forge environment
Additional information
The cases themselves are fast; the stall is most likely the test process starting up (rclcpp context / DDS) or contending for resources when many test executables run concurrently. Fix direction: investigate the startup/teardown cost of this executable under the Pixi parallel run, and either reduce per-test fixture overhead or raise the timeout for this target if the overhead is inherent.
Bug report
test_sqlite_storage(fault_manager) intermittently times out under thePixi (humble)CI job. The individualSqliteFaultStorageTestcases run in single-digit milliseconds each, so a 60 s timeout is a scheduling/resource stall under parallel test load, not a real hang. It passes on re-run.Steps to reproduce
Pixi (humble)CI job (or under heavy parallel load).test_sqlite_storageoccasionally hit the 60 s CTest timeout.Expected behavior
test_sqlite_storagecompletes well within its timeout (each case is a few ms).Actual behavior
Failing job: https://github.com/selfpatch/ros2_medkit/actions/runs/28042302548/job/83011418985
The same job passed on re-run (no code change), confirming the flake.
Environment
Additional information
The cases themselves are fast; the stall is most likely the test process starting up (rclcpp context / DDS) or contending for resources when many test executables run concurrently. Fix direction: investigate the startup/teardown cost of this executable under the Pixi parallel run, and either reduce per-test fixture overhead or raise the timeout for this target if the overhead is inherent.