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

database is locked на Windows пережил подъём порога до 30 с — неизвестно, ждал ли писатель вообще

Open
  • Is something wrong?
#1,559 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
43/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python, sqlite
Domain
database, testing

Research direction

Start with tests/test_missing_queue_sqlite.py::test_concurrent_cross_process_appends_lose_nothing and trace the failing BEGIN IMMEDIATE at glossary/json_provider.py:642, including db.connect and _queue_migrate. First make the failure summary report how long the write waited, the active timeout, and the database journal_mode; then use that measurement to determine whether the test or product needs a fix.

Written by the indexing model from the issue text.

Description

area/core bug difficulty/medium

Что не так

tests/test_missing_queue_sqlite.py::test_concurrent_cross_process_appends_lose_nothing продолжает падать на Windows database is locked после #1547, который поднял порог ожидания write-lock с 10 до 30 секунд.

Замер (01.10.2026)

  • PR #1558, прогон 36863100522, ячейка test (windows-latest, 3.14, false) — обязательная, держит мерж через ci-complete;
  • падение названо сводкой (#1541 — первый прогон, где она публикуется): воркер 2 упал на conn.execute("BEGIN IMMEDIATE") (glossary/json_provider.py:642) с sqlite3.OperationalError: database is locked;
  • в тот же день очередь мержа стояла на e2e и этой ячейке попеременно — флейк сейчас главная помеха конвейеру.

Чего мы не знаем — и это главное

Ждал ли писатель свои 30 секунд или упал сразу. Это два разных дефекта:

  • ждал ~30 с — медленная ФС под нагрузкой раннера; дело теста (4 процесса × 15 транзакций с fsync), а не продукта;
  • упал за доли секунды — busy handler не вызывался вовсе; дело продукта: CLI и web, пишущие в очередь одновременно, теряли бы добавки. Кандидаты: смена journal_mode=WAL, проглоченная в db.connect; неявная транзакция в _queue_migrate до isolation_level = None.

Повторный подъём порога без этого числа — гадание. Локально не воспроизводится (120 прогонов в #924 и сегодня), симптом даёт только искусственный порог 1 мс.

Что сделать

  • воркер теста при падении называет: сколько ждала упавшая запись, действовавший порог и journal_mode базы — следующий флейк объясняет себя через сводку; — PR #1561 (WAIT_REPORT в сообщении падения)
  • по первому такому замеру — чинить тест или продукт, в зависимости от числа.

Generated by Claude Code

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.