#164: classify a backend-error scrape as WORKER_FAILED, not a completed reply #200

Closed
agent wants to merge 2 commits from worker/cb-164-rebase-885863-8 into main

2 Commits

Author SHA1 Message Date
Dai Ha 8aaf1f7e44 #164: a backend-error failure must carry the whole scrape, not just the matched line
CI / contract (pull_request) Successful in 1m18s
CI / build (pull_request) Successful in 1m28s
The BACKEND_ERROR pattern is a heuristic. It also matches a member that forgot
fleet_reply while reporting *about* a backend error. Failing is still right --
the caller must never read a scrape as an answer -- but the reason carried only
the matched line, so the rest of the report was thrown away.

That is the same defect #164 exists to fix: information destroyed on the way to
the caller. Carry the full pane tail alongside the classification, so a genuine
backend error reads the same as before and a false positive keeps its report.
2026-08-31 10:56:15 +07:00
Dai Ha 1fcda74596 #164: classify a backend-error scrape as WORKER_FAILED, not a completed reply
CI / contract (pull_request) Successful in 51s
CI / build (pull_request) Successful in 1m33s
main already ships fleetd#164 points 1 and 2 (MIN_TURN_NANOS floor + hard-fail on an
empty/unreadable scrape, commit 3bfa828, already an ancestor of main). The rescued
worker branch worker/cb-164-empty-scrape-false-success-1a80af-3 (851ebca) reimplemented
the same two behaviours via a separate, more invasive mechanism (elapsedNanos threaded
through TurnListener/Injector/Fleetd) that would conflict with main's already-shipped
clock-injection design if merged wholesale.

Port forward only what main is genuinely missing: the narrow BACKEND_ERROR pattern
(`(?i)\bAPI Error\s*:`) that classifies a cleanly-scraped-but-backend-rejected turn as a
failure naming the member, instead of letting the error text resolve as a completed
reply. See REPORT-cb164.md for the full reasoning, what was deliberately not ported, and
the sabotage proof for the new tests.
2026-08-31 10:50:40 +07:00