From 745f0b565479a1998bb0cd3e5aa7873c77a4f4ef Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 9 Oct 2026 14:17:01 +0200 Subject: [PATCH] Issue 349: an agent waits for a check by polling --- .../00-report.md | 35 +++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 04-ISSUES/349-an-agent-waits-for-a-check-by-polling/00-report.md diff --git a/04-ISSUES/349-an-agent-waits-for-a-check-by-polling/00-report.md b/04-ISSUES/349-an-agent-waits-for-a-check-by-polling/00-report.md new file mode 100644 index 00000000..a60ee655 --- /dev/null +++ b/04-ISSUES/349-an-agent-waits-for-a-check-by-polling/00-report.md @@ -0,0 +1,35 @@ +--- +status: open +opened: 2026-10-09 +located-in: [] +fixed-by: +amended-design: +--- + +# 349. An agent waits for a check by polling + +## Symptom + +On 2026-10-09 the agents working on the mesh spent about 3.5 of 23 agent-hours in waiting loops: after a push +they asked the delivery service again and again whether the merge check had answered. A check takes five to ten +minutes, part of it waiting for a free build agent, so an agent either asks every few seconds or sleeps and +answers late. Both cost time, and the asking adds load on the controller and the bus. + +Measured from the agents' own records that day: of about 8.3 hours spent in tools, 3.5 hours were waits and +polls, 1.6 hours local runs of `merge-check.sh` and 1.4 hours local test suites. The mesh's own tools answered +fast: 232 reads of a check's verdict took 3 minutes in total. + +## Why it is an issue + +The mesh already says what happens as it happens: a build announces itself on the bus (ADR 0157), and a +delivery moves through states the delivery service keeps. Nothing lets a caller ask once and be answered when +the verdict exists. So every caller builds its own loop, each with its own interval and its own idea of when +to give up, and an agent that gives up early reports a check as missing when it is only queued. + +## What would close it + +A verb of the delivery service that waits: given a repository and a pull request, or a commit, it answers when +both required checks have a verdict, or when a bound the caller gives runs out, saying which. It answers from +the delivery's own state changes rather than by polling the forge, and a caller that times out is told where +the check stands (queued, building, judging). Checked by a test that asks before the check exists, sees no +answer until the verdict is set, and then receives it once.