Windows CI: test_chatgpt_search_pagination_default hangs in an aiosqlite call

[phernandez]

Summary

test-int/mcp/test_chatgpt_tools_integration.py::test_chatgpt_search_pagination_default intermittently hangs on windows-latest until pytest-timeout kills the run. It is not a slow test or an assertion failure — the run produces no pytest failure summary, just a timeout thread dump and exit code 1.

Observed on PR #1421, which touches none of this code (project routing).

Evidence

Run 33546084734 attempt 1, job 99983869051. The suite advanced normally to 5%, then stopped dead for ~2 minutes:

18:58:27  test_chatgpt_fetch_with_empty_title[asyncio] PASSED [  5%]
19:00:29  test_chatgpt_search_pagination_default[asyncio] ++++++++ Timeout ++++++++

Two stacks matter. The aiosqlite worker thread is inside a blocking SQLite call:

File ".venv\Lib\site-packages\aiosqlite\core.py", line 63, in _connection_worker_thread
    result = function()

…while the main thread is parked in the event loop with no basic_memory frames on the stack at all:

File "...\Lib\asyncio\base_events.py", line 2019, in _run_once

So the loop is idle, waiting forever on a SQLite call that never returns. That is a block (lock contention or a lost wakeup), not slowness — nothing is making progress to time out against.

Why this test

It is the heaviest writer in the file: it creates 15 notes in a loop through the MCP client, each one a write plus an index pass, before searching. If the cause is write-lock contention on Windows, this is the test most likely to hit it.

Note on the Python version

The thread dump shows C:\hostedtoolcache\windows\Python\3.14.7\x64\ — this job is named "Python 3.12" but ran 3.14.7, because every uv venv call was bare and resolved from .python-version. Fixed separately in #1429. Once that lands, this job will run genuine 3.12 for the first time, which may change whether the hang reproduces. Worth re-checking after #1429 merges before investing in a fix.

Not yet known

• Whether it reproduces on real 3.12, or is specific to 3.14 on Windows
• Which statement the worker thread is blocked in (the dump does not name it)
• Frequency — the rerun of this job was still in flight when this was filed

[claude]

Claude finished @phernandez's task in 55s —— View job

---

Triage

Type: Bug — an intermittent CI hang, not an assertion failure or slow test. The main thread is idle in the event loop while the aiosqlite worker thread is blocked inside a SQLite call that never returns (lock contention or a lost wakeup), so no test-side timeout logic ever fires against it.

Component: Testing/CI (test-int/mcp/test_chatgpt_tools_integration.py, Windows runner, aiosqlite/SQLite locking path). Not a Cloud-specific issue.

Priority: Medium-High. It doesn't affect running production installs, but it silently stalls Windows CI until pytest-timeout kills the job, which blocks/delays merge signal on any PR that runs this suite (as seen on #1421, which is unrelated to this test).

Complexity: Medium — root-causing a blocking-vs-slow SQLite hang under concurrent writes typically needs targeted reproduction (isolating the write-lock path used by the 15-note write+index loop) rather than a quick fix.

Duplicate check: No existing open/closed issue in this repo covers this hang; this is the only match for the test name and symptom.

Dependency note: As the issue states, #1429 (pinning uv venv to the intended Python version) is still open, not merged. This Windows job is currently running Python 3.14.7 instead of the labeled 3.12, so it's worth re-running this suite on genuine 3.12 once #1429 lands before investing further effort — the hang may be 3.14-specific.

Labeled bug.

[phernandez]

Second data point, same family, different symptom

test-int/mcp/test_concurrent_write_integration.py::test_concurrent_write_high_volume failed on windows-latest during PR #1421 (run 33558890803):

fastmcp.exceptions.ToolError: Error calling tool 'write_note':
  (sqlite3.OperationalError) database is locked

= 1 failed, 442 passed, 73 skipped, 31 deselected in 1960.50s (0:32:40) =

Different surface from the original report — an explicit lock error rather than a silent hang — but the same underlying situation: SQLite write contention on Windows under concurrency. The original report showed an aiosqlite worker thread blocked inside a call while the event loop waited forever; this one shows the lock being reported instead of waited on.

Both tests are the write-heaviest in their files (test_chatgpt_search_pagination_default creates 15 notes in a loop; this one is explicitly high-volume concurrent writes), and neither is touched by the PR it failed on — #1421 is project-path routing and changes no write or locking path.

That makes the shared cause more likely to be the Windows SQLite configuration than either test. Worth checking whether WAL mode and the busy-timeout are actually applied on Windows in the integration harness, since a missing or short busy_timeout would produce exactly this pair of symptoms — some callers erroring immediately, others parking in a blocking call.

Both occurrences were on jobs labeled "Python 3.12" that were really running 3.14 (see #1429). Once that lands, re-check whether either reproduces on genuine 3.12.

[chengyixu]

Living Memory depends on a storage layer that fails visibly: distinguish a fresh snapshot from a write that is still pending, and preserve source/session identity when a write stalls. Proactive Execution should not wait indefinitely on a memory write; a bounded busy timeout plus retry/abort receipt should surface whether the note was committed, rolled back, or needs replay. For this Windows case, a focused regression could run the 15-note loop and concurrent writes under genuine Python 3.12, assert WAL and busy-timeout settings, and verify no partial index appears after timeout. I work on Klik, a pre-launch app-first direction: https://pre.hiklik.ai/?utm_source=github&utm_medium=issue_comment&utm_campaign=memory_storage&utm_content=basic_memory_windows_lock_20260902

[phernandez]

Third symptom: the Windows unit job is now hitting its timeout

On PR #1424 (run 33562423245), Test SQLite Unit (windows-latest, Python 3.12) was cancelled at the job ceiling:

started   2026-09-01T21:42:00Z
completed 2026-09-01T22:27:19Z     = 45m19s, against timeout-minutes: 45

Not a test failure — the job ran out of wall clock. For comparison, the same job passed earlier today at 36m37s, so it is running with under 20% headroom and tips over under load.

Three symptoms, one suspected cause

symptom	where
silent hang in an aiosqlite call	test_chatgpt_search_pagination_default (original report)
sqlite3.OperationalError: database is locked	test_concurrent_write_high_volume (#1421 run)
job exceeds 45-minute timeout	Test SQLite Unit (#1424 run)

All three are Windows-only, and all three are consistent with SQLite operations serializing on Windows — a hang is a caller waiting forever, a lock error is a caller giving up immediately, and a suite that takes 37-45 minutes where other platforms take far less is the aggregate of many callers waiting a little. The busy-timeout / WAL question raised in the previous comment would explain all three rather than any one.

Care needed on the obvious fix

Raising timeout-minutes would make this symptom disappear while leaving the other two, and would remove the signal that the suite is degrading. Worth treating the 37→45 minute drift as the measurement rather than the nuisance: if Windows suite duration is climbing, that is the same story the hang and the lock error are telling.

Note also that stacked PRs run the full matrix even for docs-only changes, because the paths filter diffs against main and therefore sees every lower branch's src/** edits. That multiplies exposure to this timeout across a PR stack — #1424 changes one Markdown file and still ran the whole Windows suite.