[aw-failures] [P1] Copilot engine proxy (port 10002) refuses connections despite passing key validation — Daily Assign Issue To [Content truncated due to length] #52253

Fix the api-proxy sidecar'''s Copilot listener (port 10002) — it accepted the health check and key validation but refused all 4 chat-completion connection attempts, killing the run after the harness exhausted its retries.

Affected workflow: Daily Assign Issue To User (.github/workflows/daily-assign-issue-to-user.lock.yml)
Run analyzed: §31569260171 (failed) vs §31361150414 (last success, 2026-08-10)

Evidence

• [copilot-sdk-driver] error: ... client error (Connect): tcp connect error: Connection refused (os error 111) [ECONNREFUSED] on `(apiproxy/redacted) repeated across all 4 harness attempts between 06:19:28–06:20:24 UTC.
• The proxy'''s own startup log shows copilot proxy listening on port 10002 and key_validation ... status: valid about 30s before the first request — the listener reports ready but drops the real connection.
• audit-diff against the last successful run shows no firewall blocks and no domain-access changes — this is an internal sidecar defect, not an external network/firewall block.
• Same failure class (connection-refused to the local api-proxy sidecar) as tracked issue [aw-failures] [P1] Fix Claude Code CLI → Anthropic API connection-refused failures (proxy/firewall) #52194 — but on the Copilot listener (port 10002) instead of the Anthropic listener (port 10001), confirmed still reproducing this window on §31568090663. This indicates the sidecar defect is engine-agnostic, not Anthropic-specific.

Probable root cause

Race condition or premature readiness signal in the api-proxy sidecar: it logs "listening" before the per-engine (Copilot) listener is actually accepting connections, or the listener silently drops the sandbox'''s first real request under load.

Proposed remediation

1. Add a real accept-a-connection readiness probe per configured provider listener (not just "process started") before the harness sends its first chat request.
2. Increase the harness'''s tolerance for a first-attempt ECONNREFUSED with a short backoff before declaring the whole run failed — it currently exhausts all 3 harness retries within about 1 minute.
3. Once [aw-failures] [P1] Fix Claude Code CLI → Anthropic API connection-refused failures (proxy/firewall) #52194'''s fix lands, verify it also covers the Copilot-engine case; if not, this stays open as a distinct sidecar bug.

Success criteria

5 consecutive scheduled runs of Daily Assign Issue To User (and any Copilot-engine workflow) complete without ECONNREFUSED to the local api-proxy; add regression coverage asserting the proxy accepts a real connection before the harness'''s first request.

Parent: #52061
Related: #52194 (same failure class, different engine/listener)
Related to #52061

Generated by 🔍 [aw] Failure Investigator (6h) · agent · 165.2 AIC · ⌖ 50.6 AIC · ⊞ 5.3K · ◷

• expires on Aug 18, 2026, 11:24 PM UTC-08:00

Correction — 2026-08-19 (6h window)

3 "Execute GitHub Copilot CLI" failures today, none of which are this bug — do not fold them in here. None show ECONNREFUSED to the port-10002 proxy:

• Daily Cli Tools Tester (§32218752360) — Cloud Hypervisor guest network never came up (lo: DOWN), zero egress; filed separately as a new P0.
• Daily GitHub Docs SEO Optimizer (§32217479194) — proxy accepted connections fine; the internal copilot-sdk headless server itself timed out becoming ready (ETIMEDOUT 127.0.0.1:3002). Different layer, isolated occurrence — watching, not filing yet.
• Metrics Collector (§32209589795) — failureClass=model_not_supported, a model-selection issue, not connectivity.

No action needed on this issue from today's evidence.> Generated by 🔍 [aw] Failure Investigator (6h) · agent · 167.2 AIC · ⌖ 10.4 AIC · ⊞ 5.9K · ◷