Anything holding a long-lived TCP session to a device outside the cluster keeps a half-open socket when the node under it moves. The peer drops its side; the pod never learns, because no RST arrives and no keepalive fires.
Why this is worth writing down
The symptom is that there is no symptom. Home Assistant held seven ESTABLISHED sockets to ESPHome devices that were themselves showing "not connected". It logged nothing and retried nothing — as far as it knew, the connections were fine. The search went through logs that were empty by construction.
0B04F40A:E21A DB1E020A:17A5 01 -> 10.2.30.219 ESTABLISHED
0B04F40A:983C AA1E020A:17A5 01 -> 10.2.30.170 ESTABLISHED
...
0B04F40A:9DDA 751E020A:17A5 02 -> 10.2.30.117 SYN_SENT
The single 02 was the only device genuinely offline — and the only one Home Assistant did log and retry. That asymmetry is the giveaway: the devices being retried are fine as far as the socket layer is concerned; the ones failing silently are the broken ones.
The last open item from the conversion itself.
Anything holding a long-lived TCP session to a device outside the cluster keeps a **half-open socket** when the node under it moves. The peer drops its side; the pod never learns, because no RST arrives and no keepalive fires.
## Why this is worth writing down
The symptom is that there is no symptom. Home Assistant held **seven ESTABLISHED sockets** to ESPHome devices that were themselves showing "not connected". It logged nothing and retried nothing — as far as it knew, the connections were fine. The search went through logs that were empty by construction.
```
0B04F40A:E21A DB1E020A:17A5 01 -> 10.2.30.219 ESTABLISHED
0B04F40A:983C AA1E020A:17A5 01 -> 10.2.30.170 ESTABLISHED
...
0B04F40A:9DDA 751E020A:17A5 02 -> 10.2.30.117 SYN_SENT
```
The single `02` was the only device genuinely offline — and the only one Home Assistant *did* log and retry. That asymmetry is the giveaway: the devices being retried are fine as far as the socket layer is concerned; the ones failing silently are the broken ones.
## The check
```sh
kubectl -n home-assistant exec <ha-pod> -c home-assistant -- \
sh -c grep
Anything holding a long-lived TCP session to a device outside the cluster keeps
a half-open socket when the node under it moves. The peer drops its side; the
pod never learns, because no RST arrives and no keepalive fires.
This cost real time after the conversion. Home Assistant held seven ESTABLISHED
sockets to ESPHome devices that were themselves reporting "not connected". It
logged nothing and retried nothing, because as far as it knew the connections
were fine — so the search went through logs that were empty by construction.
The one device Home Assistant did log was the only one genuinely offline.
Records the check that settles it in one command, reading /proc/net/tcp in the
pod, and notes that reloading the integration is the lighter fix than
restarting the pod.
Placed in "Verify and restore" rather than the known-stale list: it is something
to check before calling a conversion finished, not a trap in the tooling.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
🤖Automated review — model claude-haiku-4-5-20251001 (complexity: trivial), commit c8b0d1cd4b191da8aab2b8f690f0f4a34bb29072.
Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.
Summary
This PR adds a new troubleshooting section to the baremetal conversion runbook documenting a subtle but disruptive failure mode: long-lived TCP sessions to external devices become half-open when cluster nodes migrate, appearing ESTABLISHED locally while the remote device has disconnected. The section provides clear diagnostics and solutions. No blocking issues; the documentation is technically accurate, well-placed, and follows the runbook's style.
🟢 Nits
Line 403: Port hex notation could note that users can use printf '%d\n' 0x17A5 to verify conversions inline, but the comment suffices as-is.
Tests
N/A — documentation only.
Recommendation
Looks reasonable — no blocking issues; comment above is optional.
🤖 **Automated review** — model `claude-haiku-4-5-20251001` (complexity: trivial), commit `c8b0d1cd4b191da8aab2b8f690f0f4a34bb29072`.
> Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review.
---
## Summary
This PR adds a new troubleshooting section to the baremetal conversion runbook documenting a subtle but disruptive failure mode: long-lived TCP sessions to external devices become half-open when cluster nodes migrate, appearing ESTABLISHED locally while the remote device has disconnected. The section provides clear diagnostics and solutions. No blocking issues; the documentation is technically accurate, well-placed, and follows the runbook's style.
## 🟢 Nits
- Line 403: Port hex notation could note that users can use `printf '%d\n' 0x17A5` to verify conversions inline, but the comment suffices as-is.
## Tests
N/A — documentation only.
## Recommendation
Looks reasonable — no blocking issues; comment above is optional.
<!-- pr-review:sha=c8b0d1cd4b191da8aab2b8f690f0f4a34bb29072 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The last open item from the conversion itself.
Anything holding a long-lived TCP session to a device outside the cluster keeps a half-open socket when the node under it moves. The peer drops its side; the pod never learns, because no RST arrives and no keepalive fires.
Why this is worth writing down
The symptom is that there is no symptom. Home Assistant held seven ESTABLISHED sockets to ESPHome devices that were themselves showing "not connected". It logged nothing and retried nothing — as far as it knew, the connections were fine. The search went through logs that were empty by construction.
The single
02was the only device genuinely offline — and the only one Home Assistant did log and retry. That asymmetry is the giveaway: the devices being retried are fine as far as the socket layer is concerned; the ones failing silently are the broken ones.The check
🤖 Automated review — model
claude-haiku-4-5-20251001(complexity: trivial), commitc8b0d1cd4b191da8aab2b8f690f0f4a34bb29072.Summary
This PR adds a new troubleshooting section to the baremetal conversion runbook documenting a subtle but disruptive failure mode: long-lived TCP sessions to external devices become half-open when cluster nodes migrate, appearing ESTABLISHED locally while the remote device has disconnected. The section provides clear diagnostics and solutions. No blocking issues; the documentation is technically accurate, well-placed, and follows the runbook's style.
🟢 Nits
printf '%d\n' 0x17A5to verify conversions inline, but the comment suffices as-is.Tests
N/A — documentation only.
Recommendation
Looks reasonable — no blocking issues; comment above is optional.