2 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Fable 5	77bb3729a3	refactor(tests): per-model fakes, FakeMCP and session mocks come from tests/helpers (#2825, milestone 296 area 1, batch 2) ... Second pass over the tests/ ledger after bbee0d0. fake_record(**attrs) is the one MagicMock-with-real-attributes builder (to_dict mirrors them; the note-2109 hazard documented once); fake_note/fake_task/fake_snippet/ fake_project/fake_milestone/fake_system/fake_rulebook/fake_topic/fake_rule carry each model's ordinary defaults on top of it, replacing 14 per-file factories (two rulebook trios in tool-vs-service wordings, _fake_task, _fake_ms, _fake_project, _plan_note, _fake_snippet, two _snippet adapters now one-liners over fake_snippet). FakeMCP replaces the five closure-over-a-list registrar fakes (+ _Recorder); loc() and design_token_stub() replace the paired _loc / _token / _T stand-ins; every hand-built async_session mock (9 helper defs and 14 inline copies) now starts from make_mock_session(). Call sites rewritten by AST with each file's former defaults made explicit, so behaviour is unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-21 11:13:17 -04:00
bvandeusenandClaude Opus 5	be3a0ffaf9	fix(projects): batch the summary queries — the fan-out was exhausting the pool ... Reported live: Projects and Snippets showed skeletons that never resolved, /knowledge worked intermittently. The logs named it exactly: QueuePool limit of size 5 overflow 10 reached, connection timed out, 30.00 GET /api/settings 500 30584.0ms GET /api/projects 200 30882.9ms /api/projects was not hanging — it was waiting out the 30-second checkout timeout and then returning 200 with summaries silently missing, because _attach swallowed the TimeoutError. Nobody waits 31 seconds, so it read as a hang. THE SHAPE: routes/projects.py ran asyncio.gather over every project. Each _attach called get_project_summary, which opened its own session for three queries and then called get_project_milestone_summary — which opened one more session PER MILESTONE. So 25 projects asked for roughly 250 concurrent checkouts against a pool of 15 (SQLAlchemy's default 5 + 10 overflow). That is why unrelated routes failed too. Snippets and /knowledge were never broken; they queued behind the burst and inherited its timeout. /api/settings returning 500 while /api/projects returned 200 is the same cause wearing two faces. The comment above the gather said "one backend pass instead of N+1 frontend calls". It did remove the N+1 from the network — and recreated it against the connection pool, where it is worse, because the browser had at least been serialising those calls. Now: get_project_summaries() does all projects in four queries and one session, and get_project_milestone_summaries() does all milestones in two. Two sessions total for the whole page, independent of how many projects exist. The progress calculation is extracted to _progress_from_counts and shared by both the batch and single paths, so the cancelled-exclusion rule cannot drift into two versions that disagree about whether a milestone is finished. Tests assert the SESSION COUNT, not just the values. An implementation that returned identical output while opening a session per project would pass a correctness test and reproduce the outage. Deliberately NOT done: raising pool_size. It would move the cliff rather than remove it, and this endpoint now needs two connections regardless of scale. Closes #2384. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs	2026-08-02 19:09:36 -04:00