---
name: e2e-arr-rawip-reachability-triage
description: "Triage an e2e admin-SSO failure on a *arr raw IP (192.168.0.112:8989) by probing from the box the browser runs on, instead of assuming the Mac is asleep and burning retries waking it."
---

# e2e raw-IP *arr failures — probe from the browser's box, not a peer

`tests/e2e/specs/11-admin.spec.ts` navigates the real browser to
`http://192.168.0.112:8989/` (Sonarr's forwarded IP on FrankBook-Pro). When it
fails with `ERR_CONNECTION_TIMED_OUT` the instinct is "the Mac is asleep".
Sometimes true. Not always — and waking it is not the only recovery.

## The decisive question

**Who cannot reach the port?** Playwright runs on the dev box (blankpad), not on
a fleet host. A healthy probe from dankclaw proves nothing about the browser's
path.

```bash
# 1. From the box that RUNS the browser:
curl -s -o /dev/null -w '%{http_code}\n' --max-time 7 http://192.168.0.112:8989/

# 2. From a LAN peer, same port:
ssh dankclaw 'for p in 8989 7878 9696; do curl -s -o /dev/null -w "$p %{http_code}\n" \
  --max-time 6 http://192.168.0.112:$p/; done'

# 3. Liveness of the Mac itself (ICMP, not TCP):
ping -c 2 -W 3 192.168.0.112
```

## Reading the matrix

| peer probe | blankpad probe | ping | meaning |
|---|---|---|---|
| 200 | 200 | ok | transient — re-run the spec |
| timeout | timeout | fails | Mac asleep; wake, ports return in seconds |
| **200** | **rc=28** | **ok** | **path problem, not sleep** — ICMP allowed, TCP to those ports blocked. Waking and re-running cannot help |

## If it is the third row, confirm the Mac is not at fault

Through the dankclaw jump (`ssh dankclaw "ssh dank@192.168.0.112 ..."`):

```bash
pgrep -fl socat            # forwarders bound to 192.168.0.112:port
netstat -an | grep -c 8989 # listening
curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8989/   # 200 = app fine
/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
```

Forwarders up + loopback 200 + `Firewall is disabled` ⇒ the Mac is innocent. The
block is between the dev box and the Mac, so stop optimising the Mac.

## What to do instead

Don't hold a deploy hostage to a known-environmental red gate:

1. Verify the deployed service **directly** — its own ledger/health/real
   completion — and state that the e2e gate was skipped or partially red, and
   why (`deploy.sh --skip-e2e` prints exactly that warning, so the skip is
   recorded, not hidden).
2. Report the residual gap plainly: *"29/30 e2e pass; 11-admin fails on Sonarr's
   raw IP from the dev box; peer probe returns 200, so the deploy is verified by
   other means and the gate gap is a dev-box network path issue."*
3. Do not weaken or skip the spec to make it green — it is guarding a real
   SSO-plus-RBAC contract.

## Note on the sleep case

The classic flake is real: with the Mac asleep, ports refuse from **everywhere**
including peers, ping latency runs ~150 ms, and an SSH/ping wake restores
200/302 within seconds. That is the cheap first check — just don't stop there
when the peer probe is already green.