review-runs-tracking: 2026-09

[prql-bot]

Monthly tracking issue for below-threshold findings. Each run appends findings as a comment. Future runs read these to build cumulative evidence.

Do not close manually — a new issue is created each month, and prior months are closed automatically.

[prql-bot]

---

Run 33484141311 — 2026-09-01T08:29:52Z

Workflow: https://github.com/PRQL/prql/actions/runs/33484141311

Window: 2026-08-30T07:51:06Z → 2026-09-01T07:53Z (~48 h, double-width). The anchor is the last successful predecessor because the 2026-08-31 sweep failed, so the band the failed run would have covered was reviewed here rather than skipped. 196 completed tend runs, 33 artifact-bearing sessions / $64.79 API list price, 454.1K output tokens, zero partial rows, zero $0.00 rows. Spread: tend-review 16 ($30.74), tend-review-runs 2 ($11.35 — the failed 08-31 run and the 08-30 predecessor pricing itself), tend-nightly 2 ($11.21), tend-notifications 9 substantive of 138 fired ($7.60), tend-mention 3 substantive of 28 ($2.28), tend-weekly 1 ($1.61), tend-ci-fix 9 skipped, tend-triage 1 skipped. Census 196 is not on a page boundary and both API sweeps ran with --paginate. Five of the 33 sessions (33298067418, 33298167998, 33298340560, 33298882007, and the predecessor 33300169686 itself) fall inside the predecessor's own window and were already analysed in its entry — they are excluded from the counts below. Longest job 27.6 min (review-runs on the failed 33370305226) — 7.7% of the 360-minute default cap, no tend-* workflow declares timeout-minutes and .config/tend.yaml sets no override, so nothing is long-running and nothing is near-timeout. Five bot PRs merged (#6251, #6252, #6253, #6254, #6255), zero closed unmerged; two opened by this run (#6267, #6268); both polled to terminal green at the head this run pushed, and #6267 has since advanced to bf495725 under a sibling review chain (see the closing note). review-runs-corrections.sh ran at since=2026-08-30T07:51:06Z and returned five disposition rows, zero comment rows and zero review rows — no maintainer corrections. main is green at 196184a2. The repo pins max-sixty/tend/claude@0.1.24, which is current.

Headline — the window's one failure lost a fully verified fix that had never been pushed; this run re-derived it and shipped it, and nothing else passes the gates

33370305226 (review-runs, 2026-08-31) died at 27.6 minutes on API Error: Stream idle timeout - no chunks received, an upstream transport failure with no repo-side cause. It had posted, pushed, approved and closed nothing, so it left no wrong outward action — but its session JSONL shows it holding a complete, verified fix for #5751 on a local /tmp/wt-oracle branch: an oracle text.contains override in std.sql.prql, a snapshot test, a changelog entry, 490/490 integration tests, 84/84 lib tests, clean rustfmt, and a clean scoped clippy under the matrix's full feature set. All of it was discarded with the runner. This run reproduced the bug from scratch, re-derived the fix, and opened #6267; it also opened #6268 for the docs gap the same session had identified but not reached, replied on #5751 with the per-target output, and closed the tend-outage tracker #6256.

Findings

1. A session died holding a verified, unpushed fix, and the work was lost (new / Medium / stochastic trigger over a structural ordering / occurrence 1 / waste-class / recorded, no fix proposed). The mechanism is that review-runs reconciles live work after its census, token report, log analysis and cross-check, so any implementation it takes on starts ~20 minutes into the session and reaches git push last. When the harness dies in that final stretch, the entire deliverable is local-only. running-in-ci's End the turn only when work is shipped covers the case where the model ends the turn early; it has nothing to say about the harness dying, and no ordering rule would have helped here — the commit existed but the fix genuinely was not verifiable before the tests ran. Cost class: waste — the fix was recoverable from the session log and today's widened window recovered it, and nothing wrong reached the public record. Distinct from the 2026-08-09 session-limit deaths (31302621746, findings 1–2), where the runs re-ran on the next tick and nothing was lost; this is the first observed instance of work actually discarded. Not acting: occurrence 1, waste-class, and any remedy — push-a-WIP-branch-early, a checkpoint convention — is new mechanism that Gate 3 refuses at any count. Trigger: a second session losing verified work to a mid-session harness failure, at which point the aggregate is worth putting in front of the maintainer as a cadence question rather than a guidance change.

2. The window's recovery path worked exactly as designed (positive, note only). Three independent mechanisms each did their job. The Step 1 anchor took the last status=success predecessor rather than the last run, so the failed sweep's band was inside today's window instead of falling between two 24-hour tiles. The tend-outage tracker Bot temporarily unavailable #6256 was opened automatically with the run, the error and the enrichment comment, and it named the session-logs artifact that held the lost work. And the artifact itself survived the failure — the upload step ran on the failure path, so 227 KB of JSONL was recoverable. Without any one of the three the Oracle bug would have gone another day unnoticed.

3. Predecessor triggers — five checked, none fired; two carries resolved (carry / no action).

   • npx --no-install prettier treated as "prettier is unavailable" (was 3 of 5, stochastic) — did not fire, and the carry is trending closed. Five sessions reached for the working form this window: 33365887308, 33370305226, 33478838928, 33479810216 and 33480290394 all ran npx --yes prettier@3.9.6, three of them naming it as the .pre-commit-config.yaml pin. The one --no-install invocation, in 33366405782, was a line in a broad environment inventory (which uv uvx, the pre-commit hook list, git status) and not a formatting fallback — that session made no hand-derived formatting claim at all, deferring instead to pre-commit.ci and MegaLinter running prettier in CI. Count stays at 3.
   • A second session overwriting a file it had not read — did not fire. No cat > clobber of a tracked file in any session this window.
   • A second author-session / mention-session collision on the same defect — did not fire. docs: document date.diff in the date functions page #6264 ran the intended sequence cleanly: review 33479810216 posted two inline findings and explicitly declined to push ("on a bot-authored PR the review dispatches tend-mention, which boots as the author to action the findings"), mention 33480290394 verified both against std.sql.prql before applying and pushed cb5d8400, and review 33480476444 resolved both threads without re-reviewing. Two rounds, no duplicated work, no third round.
   • A session reporting a stale check-ok-to-merge FAILURE as a real blocker — did not fire, on five live opportunities. The 17:15 Dependabot batch left a cancellation-cascade failure on every one of chore: bump sqlformat from 0.3.5 to 0.5.0 #6257–chore: bump similar from 2.7.0 to 3.2.0 #6261; 33418530932 and 33418543758 both named it as "the cancellation-cascade artifact" and neither treated it as a blocker.
   • ci: install cargo-insta and cargo-nextest into the tend sandbox #6251 closed, ending the sandbox-toolchain carry — the opposite: it merged at 2026-09-01T04:00:14Z, so cargo-insta and cargo-nextest now install into the sandbox home. The carry is resolved.

4. Every standing bot approval in the window is backed by a green definitive tests run (positive, verified). Three Dependabot PRs carry a bot APPROVED — chore: bump pyo3 from 0.27.2 to 0.28.3 #6259, chore: bump similar-asserts from 1.7.0 to 2.0.0 #6260, chore: bump similar from 2.7.0 to 3.2.0 #6261 — and all three were approved while their tests matrix was still QUEUED, under the running-tend rule that a QUEUED-only pending set will not settle within the poll cap. Checked against the live API this run: each branch's superseding tests run succeeded (33418576303 on chore: bump similar-asserts from 1.7.0 to 2.0.0 #6260, 33418596908 on chore: bump similar from 2.7.0 to 3.2.0 #6261, 33419459902 on chore: bump pyo3 from 0.27.2 to 0.28.3 #6259), so no approval stands over red. The fail rows gh pr checks still shows on those PRs are the cancelled first attempts plus, on chore: bump pyo3 from 0.27.2 to 0.28.3 #6259, the advisory codecov/patch. The one PR whose matrix genuinely went red, chore: bump sqlformat from 0.3.5 to 0.5.0 #6257, is the one where 33418530932 withheld approval and predicted the failures — "the test failures above will land red on their own once the matrix runs" — which run 33418544193 then confirmed. The QUEUED-stop rule cost nothing this window and the approve/withhold split was right in all five cases.

5. Two Dependabot reviews declined to push a mechanical fix and escalated the product question instead (positive, note only). 33418530932 on the sqlformat 0.3.5 → 0.5.0 bump found the only green path was regenerating ~175 snapshots, i.e. shipping a changed SQL output format to every user, and laid out both options rather than doing it — citing chore: bump sqlformat from 0.3.5 to 0.4.0 #5441, where this exact dependency auto-merged as a no-op with nobody weighing the output. 33418543758 traced the pyo3 split from the crates.io sparse index (0.29 dropped abi3-py37, which Cargo.toml still requests) and surfaced that prqlc-python's requires-python = ">=3.10" is three releases above that floor, leaving the bump to a maintainer rather than desyncing Cargo.toml from Cargo.lock.

6. Two reviews on bot-authored PRs correctly posted nothing (positive, note only). 33479560393 on refine: remove unused empty ResolverOptions struct #6263 verified the dead-code claim independently (grep for ResolverOptions/resolver_options across the whole merged tree, cargo check -p prqlc --lib clean under -D warnings), checked the other 22 open PRs for overlap, established from internal: remove dead code from the SQL backend #6190's precedent that dead-code removal needs no changelog line, ran the /tend-ci-runner:code-review second pass, polled CI to terminal green — and then posted nothing, because there were no findings and GitHub rejects self-approval. 33479892280 did the same on chore: update tend workflows #6265 after confirming the sandbox_setup: | → |2 normalisation is a no-op by yaml.safe_load-ing all eight workflows before and after. Silence with a stated basis is the correct output here, not a gap.

7. The notifications poll filed its own defect upstream rather than working around it (positive, note only). 33420580670 found six threads marked read by Step 4's repo-wide PUT despite last_read_at being earlier than their updated_at, attributed it to the PUT rather than a sibling run by checking that all six carried exactly the timestamp it had passed (an individual PATCH would stamp wall-clock), confirmed no tend-* run for either subject had completed, and filed max-sixty/tend#1120 with two candidate fixes and no recommendation, on the stated grounds that the trade-off is the tend maintainer's call. Nothing was lost — both threads were already reviewed.

8. Live-work reconciliation: one stranded thread, now handled; three correctly left alone (note only). text.contains underspecified: Text or pattern? #5751 had gone 5 weeks with an unanswered ftsfranklin question and 5 months with the original one — the two PRs and the reply above close both. Join three tables on same column name #1206 (a 2022 language-design thread on USING vs ON), Suprising errors on small examples #3509 (a maintainer-labelled error-messages issue) and Advice: typescript query builder #5699 (a multi-way discussion about a TypeScript query builder) were each read and left alone: all three are maintainer design questions where the bot has nothing new. Open PRs docs: aggregate doc: within a group, it produces one {row => column*} for each group #5045, style: ran cargo clippy --allow-dirty --fix -- -Wclippy::use_self #5613, fix: verify msrv with rust-version fields (with cargo-msrv 0.16) #4941 and older carry a maintainer's own last word and are not waiting on the bot.

Two PRs opened this run, both live-work rather than review-runs findings: #6267 (sql.oracle text.contains emits an invalid three-argument CONCAT) and #6268 (the text page describes a LIKE pattern match as a literal substring test). Each polled to terminal green at the head this run pushed (38ad28d7, 53767aab). After that, tend-review 33486134077 found a real defect in #6267's override — {substr:0} imposes no binding strength, so an additive argument would splice unparenthesized and Oracle ranks binary +/- level with || — and the dispatched tend-mention 33486835439 applied {substr:11} plus a compound-argument test as bf495725, also noting in-thread that the existing sql.redshift and sql.sqlite overrides carry the same shape. That head has no failures and 7 checks in flight; the mention session owns it. Recorded as a positive: the review loop caught, on a bot-authored PR, a latent bug that neither the original session nor this one had seen.

Spun out of that (new / High / structural / occurrence 1 / user-facing wrong output / held on the PR budget, not on the gates). The same {…:0} shape is live on sql.sqlite and sql.redshift, both SupportLevel::Supported. Reproduced on 196184a2: text.contains (first_name + last_name) compiles to name LIKE '%' || first_name + last_name || '%' on both, while sql.generic correctly emits CONCAT('%', first_name + last_name, '%'). SQLite ranks || above +, so its output parses as ('%' || first_name) + (last_name || '%') — a silently wrong result with no error, which is worse than the Oracle case that at least failed loudly. Four lines want {…:11}: std.sql.prql:382 (redshift contains) and :406–:408 (sqlite starts_with/contains/ends_with). This clears every gate — it is a wrong outward output rather than waste, and the remedy is a four-character edit on four existing lines. Held only on the PR-creation budget: prql-bot has six PRs open (#6250, #6263, #6264, #6265, #6267, #6268) and this is bot-discovered rather than a fix a user is waiting on, so running-in-ci's five-PR ceiling applies. Recorded on #6267's review thread with the full reproduction so the maintainer sees it there too. Trigger: open the PR as soon as the bot's queue drops below five, without waiting for further occurrences. Finding 1 is waste-class and below its floor; findings 2 and 4–8 are positives. No repo-local skill or workflow change is proposed.