mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-09-29 18:51:43 +02:00
maziggy
14da007c7d
The concurrent-dispatch tests went red on the Docker shard with "expected all 6 printers to be uploaded to concurrently, but the high-water mark was 4", on a scheduler that was dispatching all six correctly. peak == 6 is the claim that the sixth dispatch reaches its upload before the first one finishes, and the dispatches do not arrive together: each runs a preamble of database work first. So the assertion was a race between that spread and a fixed 0.15 s sleep. Measured here the spread is ~14 ms; on the runner it passed 150 ms. Padding the sleep would only move the threshold and slow every test that uses it. _UploadRecorder(assemble=True) now holds each call until every upload the pass launched has arrived, reading len(_inflight), which is filled synchronously at launch and is therefore the batch size. That states the property the peak assertions are about, directly and with no time in it, and it ends sooner than the sleep it replaces - the file runs 7.0s to 5.9s. _BATCH_DEADLINE_SECONDS bounds it so a dispatch that really has gone serial fails on its peak assertion instead of hanging to the pytest timeout. test_check_queue_returns_without_awaiting_the_uploads keeps the sleep, with the reason recorded next to it: it reads the rows while the uploads are open, and an assembled batch releases as soon as it is complete, which would let the dispatches flip those rows mid-assertion. The test engine also takes the application's own _set_sqlite_pragmas listener rather than a copy, so the file is opened the way the running system opens one - WAL, synchronous = NORMAL, a 15 s busy timeout. SQLite's defaults spend an fsync per commit and lock the whole file, which made a dispatch's preamble cost more than the upload it precedes. That is what turned the previous commit's move to a file-backed database into a visible failure. Verified in both directions rather than by a green run: with two printers' preambles delayed by a second, the old recorder reports exactly the "high-water mark was 4" the runner saw and the shared library test reports 3 == 4, while the assembling recorder passes the same scenario. Without the induced skew, ruff is clean, the full backend suite is green at 12224 passed, and ten consecutive runs of the file pinned to one core show no failures.