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

fix(tests): флейк test_concurrent_cross_process_appends_lose_nothing на Windows, и причина падения скрыта

Open
  • Is something wrong?
#924 4 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
56/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python, sqlite
Domain
databases, testing

Research direction

Start with tests/test_missing_queue_sqlite.py, especially the worker process assertion, and run test_concurrent_cross_process_appends_lose_nothing on Windows if possible. Capture the worker's stderr to identify the failure before deciding whether the timeout or transaction handling needs attention in src/stepik_grader/db.py. Done means failures expose a useful cause and concurrent appends still lose no records, without skipping the test.

Written by the indexing model from the issue text.

Description

area/core bug difficulty/medium owner-action породило правило

Найдено на прогоне CI для PR #914 — документного PR, не трогающего ни кода, ни тестов. Эпик #915, риск-группа «сейф-нет и гейты» (#921).

Что произошло

Джоб test (windows-latest, 3.13, false) в run 31475822457:

FAILED tests/test_missing_queue_sqlite.py::test_concurrent_cross_process_appends_lose_nothing
AssertionError: воркер завершился с ненулевым кодом
assert 1 == 0
 +  where 1 = wait(timeout=120)
===== 1 failed, 3099 passed, 36 skipped in 413.46s =====

Тот же коммит на Linux и macOS зелёный, локальный прогон теста зелёный, последний прогон main (run 1003) зелёный. То есть это нестабильность, а не регресс.

Два отдельных дефекта

1. Причину падения невозможно узнать. tests/test_missing_queue_sqlite.py:159 проверяет только код возврата:

assert proc.wait(timeout=120) == 0, "воркер завершился с ненулевым кодом"

stdout и stderr воркера не перехватываются и не печатаются. В логе CI есть код 1 и нет ни строчки traceback — диагностировать нечем, приходится гадать. Это чинится независимо от самой нестабильности и делает следующий такой отказ разбираемым.

2. Вероятная причина — BUSY_TIMEOUT_MS = 10000 (src/stepik_grader/db.py:67) при четырёх конкурентных писателях по 15 транзакций каждый. На Windows-раннере файловые операции ощутимо медленнее (весь набор идёт 413 с против ~210 с локально), и sqlite3.OperationalError: database is locked по истечении десяти секунд становится достижим. Гипотеза требует подтверждения — что вернёт пункт 1.

Что сделать

  1. Перехватывать вывод воркеров (capture_output=True) и включать stderr упавшего процесса в текст assert — тогда следующий отказ сразу назовёт причину.
  2. По полученному traceback: либо поднять busy_timeout для этого сценария, либо ретраить транзакцию на SQLITE_BUSY, либо сделать тест устойчивым к медленной ФС, не ослабляя сам acceptance-критерий «ничего не потеряно».
  3. Не заменять assert на xfail/skip: проверяемое свойство — межпроцессная сохранность очереди (issue #552, ADR-0011) — реально важно, и отключение теста вернёт исходную проблему невидимой.

Связанные находки аудита

QA-2-01 — инвентарь пропусков слеп к модульному pytestmark; QA-2-02 — guard «набор не скипнулся целиком» считает собранные тесты, а не выполненные. Оба про то же самое: нестабильность и пропуски в наборе сейчас плохо наблюдаемы.

Dominant language
Python
Stars
3
Forks
6
Avg merge
2h 41m
Merged PRs (30d)
48

Getting set up

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 ArtVsMark/Stepik-Python-Grader

All issues in ArtVsMark/Stepik-Python-Grader

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.