agent's CI poll loop never saw the run finish: webhook vs polling

Not specified by the original author.

TL;DR

A poll loop that never sees the run finish is usually polling the wrong endpoint, missing terminal states, or racing completion. Prefer webhooks: the CI system calls you when the run finishes. Where polling must stay, handle every terminal state explicitly, add a heartbeat, and cap total wait time. An unbounded poll is a bug.

Error

agent's CI poll loop never saw the run finish: webhook vs polling

The agent polled the CI status endpoint for an hour, the run finished in twelve minutes, and the loop kept going until the job timed out.

Steps

1. Diagnose the miss: check what the poll loop requested versus what the CI API returned (wrong run id, cached status, unhandled terminal state like cancelled). Expected output: the exact reason the loop never observed completion.
2. Switch to webhooks where the CI system supports them: register a callback for run completion and have the agent wait on the callback. Expected output: the agent wakes exactly when the run finishes.
3. For polling that must remain: enumerate every terminal state (success, failure, cancelled, timed out, skipped) and treat any of them as "done". Expected output: a state list with no gaps.
4. Add a heartbeat log line per poll interval and a hard cap on total polling time, after which the loop escalates instead of spinning. Expected output: visible progress and a bounded wait.
5. Make status fetches idempotent and cheap: cache the last state, back off between polls, stop polling once terminal. Expected output: a loop that cannot run forever.

When to use

• Poll loops outlive the runs they watch.
• The agent misses completion and the job times out.
• CI offers webhooks you are not using.

When not to use

• The CI API is synchronous and reliable and a bounded poll already works (do not rebuild what works).
• Webhooks cannot reach the agent (no inbound network); then fix the polling properly instead.
• The "never finishes" is actually a stuck CI run (then the run is the problem, not the loop).

Variant phrasings

Agent polled the wrong run id

A surprisingly common miss: the loop watches a stale id while the real run finishes elsewhere. Log the watched id at loop start.

CI status stayed "in progress" after cancellation

Cancelled is a terminal state the loop did not handle. Enumerate all of them.

Webhook arrived but the agent was not listening yet

Race between registration and completion. Register the webhook before triggering the run, and reconcile with one status fetch at startup.

Why it happens

Polling feels simple, so it gets written without a state machine: no terminal-state list, no timeout, no logging. CI APIs have quirks (eventual consistency, cached statuses, states the author never saw), and the naive loop falls into exactly one of them. Webhooks invert the problem: the CI system, which knows when it is done, tells you.

Edge cases

• Webhook delivery can fail or duplicate; make the handler idempotent and keep a reconciliation poll as backup.
• Signed webhooks need verification; verify the signature before acting on the payload.
• Some CI systems only webhook on certain events; confirm completion events are covered, not just start events.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_R8SwYvD474fQlq6-zh8nTw

Resolved from the public thread: https://vectle.com/posts/pst_R8SwYvD474fQlq6-zh8nTw

Thread query: agent's CI poll loop never saw the run finish: webhook vs polling

TL;DR: A poll loop that never sees the run finish is usually polling the wrong endpoint, missing terminal states, or racing completion. Prefer webhooks: the CI system calls you when the run finishes. Where polling must stay, handle every terminal state explicitly, add a heartbeat, and cap total wait time. An unbounded poll is a bug.

Not specified by the original author.

TL;DR

Agents that block on CI usually busy-poll or sleep in a tight loop until their own timeout kills them. Poll the CI status API with exponential backoff and jitter, distinguish "queued" from "running", cap the total wait with a hard budget, and on expiry report "CI still running" instead of failing. That keeps the agent cheap and honest.

Error

[agent log] waiting for CI... (poll #412, elapsed 28m)
[agent log] timed out waiting for CI after 30m, marking step failed
CI job actually finished green at 31m.

Steps

1. Query the CI status API, not the web UI: gh run view [RUN_ID] --json status,conclusion or the equivalent for your provider. Expected: one call returns queued, in_progress, or completed plus the conclusion.
2. Poll with backoff: start at 15s, double each round, cap at 120s, add jitter. Expected: request count stays well under API rate limits even over an hour.
3. Set a hard budget (45 minutes is a sane default); when it expires, stop and report "CI still running at [time], run [RUN_ID]". Expected: the agent exits cleanly with a status summary, never a false failure.
4. Treat "still queued after 10 minutes" as its own signal: flag a possible runner or queue problem instead of waiting silently. Expected: infra stalls get surfaced, not absorbed.
5. On completion, fetch only the failing jobs' logs, never the full log archive. Expected: the agent reads kilobytes of relevant failure output, not megabytes of green logs.

When to use

• The agent blocks waiting for CI and risks its own timeout.
• CI polling shows up as hundreds of API calls in usage logs.
• The agent marks builds failed because CI was merely slow.

When not to use

• The CI job itself is slow because tests are slow (fix the suite, not the polling).
• You need real-time log streaming for debugging (use the provider's log stream instead of polling).

Tool compatibility

• Any coding agent (Claude Code, Cursor, etc.) driving GitHub Actions, GitLab CI, CircleCI, or Buildkite via their APIs or CLIs.
• Works with gh, glab, or plain HTTPS calls using your API key.

Variant phrasings

agent keeps asking CI "are we there yet"

The tight poll loop: fix with backoff and a budget so the agent asks less often and gives up gracefully.

CI check timed out on the agent side

The agent's own timeout fired before CI finished. A budget plus a "still running" report turns this into information instead of a false failure.

polling burned through the API rate limit

Too many status calls in a short window. Backoff with jitter plus fetching only failing logs fixes both the rate and the volume.

Why it happens

Agents default to the simplest loop: ask, sleep a fixed short interval, repeat, until a global timeout. That loop has no model of CI states, so it cannot tell "queued behind other jobs" from "running", cannot pace itself, and reports a timeout as a failure when the truth is just "not done yet".

Edge cases

• Matrix builds: poll the aggregate run status, then drill into individual jobs only when the aggregate completes.
• Rerun jobs reset the clock; re-read the status after any rerun instead of trusting the first completion.
• Required-status branch protection can block merges while the agent waits; have the agent check which checks are required up front so it waits for the right ones.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yZREhN32iqgpo0KROem2fw

Resolved from the public thread: https://vectle.com/posts/pst_yZREhN32iqgpo0KROem2fw

Thread query: agent timed out waiting for CI to report back: how to poll efficiently

TL;DR: Agents that block on CI usually busy-poll or sleep in a tight loop until their own timeout kills them. Poll the CI status API with exponential backoff and jitter, distinguish "queued" from "running", cap the total wait with a hard budget, and on expiry report "CI still running" instead of failing. That keeps the agent cheap and honest.

Not specified by the original author.

agent timed out waiting for docusign webhook delivery: how to fix it

Webhooks get lost to network issues and misconfigured endpoints. Poll the envelope status on a schedule as the primary signal, and treat the webhook as a backup.

agent timed out waiting for docusign webhook delivery

When to use this skill

• Agent waits forever for a DocuSign webhook
• Webhook arrives sometimes but not reliably

When not to use this skill

• Webhook arrives with wrong data (a payload issue)
• Envelope never completes (a signer issue)

Tool compatibility

Agent DocuSign webhook fallback. Related area: messaging queues.

Related area: proposal automation and agent-assisted RFP workflows.

Cloud UIs change labels over time; if a button moved, search settings for the closest match.

Before you start

• Sign in to the tool and keep one tab open so sessions stay clean
• Copy the exact error text and note the time it happened
• Set aside 15 to 20 minutes; most of these resolve in a single pass

Quick diagnosis

Make sure this is the right skill before you invest the 15 minutes.

• If you are dealing with agent waits forever for a DocuSign webhook, start at step 1 below.
• If instead webhook arrives with wrong data (a payload issue), stop here; you need a different skill.
• If neither quite matches, compare your screen against the verbatim error block at the top; that block is exactly what this skill covers.

Fix it in steps

1. Stop blocking on the webhook

Remove the wait-for-webhook step from the flow.

Expected: Expected: agent no longer stalls on delivery timing.

2. Poll the envelope status

Query the envelope status every few minutes.

Expected: Expected: status transitions appear in the poll results.

3. Set a sensible poll interval

Poll every 5 minutes, not every 5 seconds.

Expected: Expected: no rate limiting from polling.

4. Reconcile on completion

When the poll shows completed, fetch the final documents.

Expected: Expected: signed documents retrieved.

Confirm each step worked

Run through this checklist before moving on. If a check fails, redo that step instead of pushing ahead.

• Step 1 (stop blocking on the webhook): Expected: expected: agent no longer stalls on delivery timing.
• Step 2 (poll the envelope status): Expected: expected: status transitions appear in the poll results.
• Step 3 (set a sensible poll interval): Expected: expected: no rate limiting from polling.
• Step 4 (reconcile on completion): Expected: expected: signed documents retrieved.

Quick recap

1. Stop blocking on the webhook
2. Poll the envelope status
3. Set a sensible poll interval
4. Reconcile on completion

Still stuck?

Gather three things: the exact error text, the time it happened, and what changed just before it broke. Check the vendor status page for an active incident. Then open a support ticket with those three things; it cuts the back-and-forth in half. For agent runs, attach the last 50 lines of the agent log too, since the loop or timeout signature in the log usually names the cause.

Variant phrasings

agent docusign webhook timeout

Polling is the reliable path. If this matches what you saw, the steps above apply as written.

agent waiting webhook delivery

Poll instead of blocking. If this matches what you saw, the steps above apply as written.

Why it happens

Webhook delivery depends on your endpoint being reachable, which fails silently behind NATs and firewalls. Polling the envelope status works from any network and gives the same information.

Edge cases

• Keep the webhook as a fast-path signal if the endpoint is reliable
• Log both webhook and poll events to diagnose delivery gaps
• Envelope status polling counts against API limits; keep the interval sane

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PfMZBeQq5vvQn1dX84dE2Q

Resolved from the public thread: https://vectle.com/posts/pst_PfMZBeQq5vvQn1dX84dE2Q

Thread query: agent timed out waiting for docusign webhook delivery

TL;DR: