fix: isPortBusy preflight misses IPv4-only occupant#94463
Conversation
…ily flaw as openclaw#94379) Route isPortBusy through checkPortInUse (from src/infra/ports-inspect.ts), which probes all four endpoints (127.0.0.1, 0.0.0.0, ::1, ::) instead of a bare tryListenOnPort that binds the IPv6 wildcard (::) on dual-stack hosts. An occupant listening only on 127.0.0.1 (IPv4-only) does not conflict with that bind, so isPortBusy returns false (free) when the port is actually taken. This is the same address-family flaw fixed for the CDP preflight in openclaw#94379 / openclaw#94415, now fixed for the gateway --force flow. Closes openclaw#94426. Co-Authored-By: Claude <[email protected]>
|
Codex review: needs real behavior proof before merge. Reviewed June 20, 2026, 6:03 PM ET / 22:03 UTC. Summary PR surface: Source -5. Total -5 across 2 files. Reproducibility: yes. by source inspection: current main calls Review metrics: none identified. Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Reuse the multi-endpoint probe for Do we have a high-confidence way to reproduce the issue? Yes by source inspection: current main calls Is this the best way to solve the issue? No, not as-is. Reusing Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against f18ff7551edc. Label changesLabel justifications:
Evidence reviewedPR surface: Source -5. Total -5 across 2 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
Summary
isPortBusythroughcheckPortInUse(fromsrc/infra/ports-inspect.ts) which probes all four endpoints —127.0.0.1,0.0.0.0,::1,::— instead of a baretryListenOnPortthat binds the IPv6 wildcard (::) on dual-stack hosts127.0.0.1) does not conflict with an IPv6 wildcard bind, soisPortBusyreturnedfalse("free") when the port was actually takengateway --forceflowcheckPortInUseis exported fromports-inspect.ts(was internal), enabling reuse across the codebaseFixes #94426
Linked context
Real behavior proof (required for external PRs)
Behavior addressed:
isPortBusyinsrc/cli/ports.tsnow correctly detects IPv4-only port occupants by probing all four loopback endpoints instead of only the IPv6 wildcard.Real setup tested: Linux x86_64, Node 22, OpenClaw local dev instance (worktree)
Exact steps or command run after fix:
After-fix evidence:
Observed result after the fix: All 15 port-related tests pass. The
isPortBusyfunction now correctly delegates tocheckPortInUsewhich tries binding to127.0.0.1,0.0.0.0,::1, and::— catching IPv4-only occupants that the old singletryListenOnPortcall (binding::) would miss.What was not tested: End-to-end
gateway --forceintegration test with an actual IPv4-only listener (the existing unit tests cover the isolation; E2E port-ownership tests require root/network-namespace setup not available in this environment).Tests and validation
src/infra/ports.test.tsandsrc/infra/ports-probe.test.tstests pass (15/15)checkPortInUsewas already tested indirectly throughinspectPortUsagewhich calls it whenlsofreturns no listenerssrc/cli/ports.test.ts(background run passed)Risk checklist
Did user-visible behavior change? (
No)Did config, environment, or migration behavior change? (
No)Did security, auth, secrets, network, or tool execution behavior change? (
No)What is the highest-risk area?
forceFreePortAndWaitfunction usesisPortBusyas a preflight check and post-kill verification. If this change caused any false-positive "busy" returns, it could lead to unnecessary port kills. This is mitigated by the conservative mapping: only checkPortInUse's"busy"result maps totrue;"free"and"unknown"both map tofalse.How is that risk mitigated?
"unknown"maps tofalse, so unexpected OS errors won't trigger a false port-busy reportCurrent review state
What is the next action?
What is still waiting on author, maintainer, CI, or external proof?
gateway --forceintegration test with an actual IPv4-only port occupant is desirable but requires root/netns setupWhich bot or reviewer comments were addressed?
🤖 Generated with Claude Code