Frank
4b82f35354
Tracked the harness artifacts accumulated on blankpad (blank@), matching the existing convention for the --home-dank-* memory stores and the 36 already-tracked managed-skills. managed-skills (9): authentik-proxy-provider-app-link, dankclaw-guard-chain-layer-diagnosis, e2e-arr-rawip-reachability-triage, halogen-kv-pool-fit, lan-client-split-dns-fix, noctalia-reference, rootless-quadlet-log-retrieval, ssh-key-bootstrap-no-sshpass, swapfile-resize-safe-ordering. memories (2 stores): --home-blank-.omp-- (dotfiles_git, handy_lifecycle, input_permissions) and --home-blank-Projects-serverAppConfig-- (frank_large_quadlet). Secret sweep before staging: no PEM blocks, no credential literals. Content is fleet topology/IPs only, same class as the tracked dank stores.
3.0 KiB
name, description
| name | description |
|---|---|
| e2e-arr-rawip-reachability-triage | 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.
# 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 ..."):
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:
- 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-e2eprints exactly that warning, so the skip is recorded, not hidden). - 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."
- 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.