mirror of
https://github.com/turnstonelabs/turnstone.git
synced 2026-08-27 14:24:47 -06:00
1b40ae79f9
Three issues from the Copilot review on PR #457: 1. SQLite race in bulk_close_stale_orphans (Copilot): the SELECT-then- UPDATE flow doesn't re-apply the eligibility predicates on the UPDATE, so a row that gets touch_workstream-bumped (or set_state- transitioned) between the two statements would still be flipped to closed. Postgres dodges this via UPDATE...RETURNING (one atomic statement); SQLite needs the explicit re-application. Fix: rebuild the WHERE conditions list once, apply on both SELECT and UPDATE, then SELECT-back by ``state='closed' AND updated=now`` to get the accurate closed-id list. A row that became fresh between the two statements skips the UPDATE entirely. 2. SQLite IN-clause bind-parameter limit (Copilot): default 999 cap could be exceeded on a backlog reap (e.g. after a long outage). Chunked the candidate id list at 500 — same chunk size prune_workstreams (line 453) uses for the same reason. 3. Wall-clock-dependent test asserts (Copilot, two locations): the tests asserted ``updated > '2024-01-01T00:00:00'`` which is fragile on systems with skewed clocks or pre-2024 dates. Replaced with ``updated != stale_seed`` — captures the same intent (the value was bumped) without depending on wall-clock date. Two ``...``-as-no-op flags from github-code-quality were false positives — ``...`` is the standard Python idiom for Protocol method bodies and matches every other method in _protocol.py. No code change.