Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Tests] main CI has been red for its last 60 runs: deterministic Windows failure, Windows snapshot drift, and a cluster of timing-flaky TUI tests

Closed
  • Is something wrong?
#741 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
github-actions, python
Domain
ci-cd, devtools, testing

Research direction

Start with tests/test_audit_log_export.py:342 and tests/test_quarantine_vault_modal.py:96-106, 200-221; compare the fixed waits with the worker completion behavior described in the issue. Review the named TUI tests and .github/workflows/ci.yml:135-138 to assess the platform failures. Done means the portability and timing failures are reliably fixed and CI can report results across all three operating systems.

Written by the indexing model from the issue text.

Description

bug

Summary

In the last 60 runs of CI Pipeline, the push runs on main concluded 11 failure, 5 cancelled and 0 success. PR runs: 24 failure, 6 cancelled, 0 success. Because Required CI is never green, the branch ruleset and auto-merge gate cannot pass without manual intervention. The failures fall into three groups.

1. Deterministic Windows failure (test bug)

tests/test_audit_log_export.py::test_export_audit_log_secondary_db_by_session_id fails on every Windows run (39268199044, 39269080076, 39268048895, 39267923608, 38966156287, 38964773442):

>       assert rows[0]["source_path"] == "/src/sec.txt"
E       AssertionError: assert '\\src\\sec.txt' == '/src/sec.txt'
tests\test_audit_log_export.py:342

The history layer normalises paths with os.path.normpath, but the test hard-codes POSIX separators.

2. Windows TUI snapshot drift

The "Terminal Interface Snapshot Validation" step fails on windows-latest (runs 39269234922 and 39267479262).

3. Timing-dependent TUI and DB tests (flaky on macOS and Ubuntu, and locally)

Seen failing intermittently in CI annotations:

  • test_template_gallery_ui.py::test_wizard_modal_switch_and_checkbox_announcements: 3 macOS runs
  • test_tui.py::test_tui_conflict_policy_settings_and_tree_indicator: 2 macOS runs
  • test_tui_history_rollback.py::test_rollback_execution_success: macOS
  • test_extraction_preview.py::test_settings_modal_extraction_tab: ubuntu, assert '50' == '75' at :100. The DensitySlider reactive default (reactive(50), app/ui/tui.py:569) and its watch_value → Changed → input sync (:2027-2034) may race with the initial value.
  • test_cascade_scrubbing_consent.py (3 tests), test_dropzone_modal.py::test_dropzone_modal_paste_and_trigger, test_db_conn.py::test_concurrent_db_conn_access, test_sqlite_step_ledger.py::test_bidirectional_path_mapping_and_collision_restoration

I reproduced flakiness locally on Linux. Two consecutive runs of pytest -m "not slow" -n 4 on the same checkout and environment:

  • Run 1: 1,392 passed (failures were only missing-optional-group problems, tracked in #739)
  • Run 2: 2 failed, 1406 passed in 338.67s:
FAILED tests/test_quarantine_vault_modal.py::test_quarantine_vault_modal_records_loading_and_filtering@tui
    assert table.row_count >= 1   ->  0
FAILED tests/test_quarantine_vault_modal.py::test_quarantine_vault_modal_reinspect_action@tui
    assert 'STAGED' in ('QUARANTINED', 'CLEARED', ...)

Both passed in run 1. These tests wait for @work(thread=True) workers (fetch_records_async, execute_reinspect_async) with a fixed await pilot.pause(0.5) instead of waiting for the worker to finish.

Location

  • tests/test_audit_log_export.py:342
  • tests/test_quarantine_vault_modal.py:96-106, 200-221, plus the TUI tests above. Many use the pilot.pause(<seconds>) pattern.
  • .github/workflows/ci.yml:135-138: the matrix has no fail-fast: false, so one OS failing cancels the others and hides their results

Expected vs actual

  • Expected: main is green, and failures reproduce deterministically.
  • Actual: main is permanently red, and the red is a mix of one real portability bug and timing races.

Suggested fix

  • Make the audit export test separator-agnostic (os.path.normpath("/src/sec.txt"), or compare Paths).
  • Regenerate Windows snapshots, or normalise platform-specific glyphs and paths in the snapshot harness.
  • Replace fixed pilot.pause(x) waits with await app.workers.wait_for_complete() or await pilot.wait_for_scheduled_animations(), plus polling on the expected condition with a timeout.
  • Add pytest-rerunfailures only as a temporary quarantine, with a tracked list. Consider fail-fast: false so all three OS results are visible.
  • Turn on -p randomly or --random-order in a nightly job to surface order-dependence (see the module reloads mentioned in #738).

Severity

high

Dominant language
Python
Stars
1
Forks
0
Avg merge
10h 10m
Merged PRs (30d)
420

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from fderuiter/sortify

All issues in fderuiter/sortify

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.