feat: wait for the gateway and report where it is listening - #72
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: needs changes before merge. Reviewed September 17, 2026, 11:01 PM ET / September 18, 2026, 03:01 UTC (Revision 5). ClawSweeper reviewWhat this changesThe Windows launcher waits for the gateway to listen, reports startup progress and an identifiable port, and gives clearer startup-failure guidance. Merge readiness⛔ Needs changes before merge - 1 item remains The bounded startup wait remains useful and is absent from current main and the latest release. Earlier findings are addressed, and no introduced blocking defect was found. Priority: P2 Review scores
Verification
How this fits togetherThe Windows launcher manages an OpenClaw gateway inside an isolated session. Its gateway controller turns start requests and session observations into lifecycle results, which the CLI renders as human-readable output or JSON. flowchart TD
A[Gateway start command] --> B[Prepare owned session]
B --> C[Launch gateway]
C --> D[Inspect process and listeners]
D --> E{Listening or wait finished?}
E -->|Keep waiting| D
E -->|Finished| F[Report state and identifiable port]
Before merge
Agent review detailsSecurityNone. Review metrics
Technical reviewBest possible solution: Keep listener readiness in the existing controller and presentation in the CLI, while leaving endpoint configuration and token retrieval to OpenClaw. Do we have a high-confidence way to reproduce the issue? Not applicable as a feature review; source confirms that main currently returns after one inspection, while the proposed polling paths are covered by focused tests. Is this the best way to solve the issue? Yes. Reusing the existing ownership-aware inspection path and renderer is a focused solution, and port-only reporting avoids guessing upstream TLS or Control UI settings. AGENTS.md: not found in the target repository. Codex review notes: model internal, reasoning medium; reviewed against b904c90c1439. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (4 earlier review cycles)
|
d7579e5 to
9b1fe49
Compare
9b1fe49 to
c375b56
Compare
c375b56 to
674eb68
Compare
`clawctl gateway-service start` launched the gateway, inspected once, and then handed the user a status command to run themselves. A process that exists is not a usable gateway, and the address it ended up on -- the thing a user actually needs -- was never reported at all. Wait for the listener, narrate the wait, and say where it is. - Poll until a listener the gateway owns appears or a fixed budget is spent, driving every delay through the controller's injected TimeProvider so the whole budget runs instantly in a test. Only the "alive but not bound yet" case is waited on: an inspection error or a process that has already gone is a decided outcome, and spending the budget on it would make a failed start feel like a hang. - Report progress as semantic stages from the controller rather than printing from it, because starting the gateway also runs from a logon task where nothing is watching and any console write would be wrong. - Show the stages as a spinner on an interactive terminal and as one line per stage anywhere else. Narration is off entirely under --json, so standard output still carries exactly one document. - Report the Control UI address, which is the one a person opens. OpenClaw serves the Control UI over HTTP and the gateway protocol over a WebSocket on the same port, so the two are built separately and never substituted. - Resolve the port from what was observed, never from the upstream default. OpenClaw owns the port, so a guess would send a user to a port nothing is listening on; an unknown port reports no address. - Offer `openclaw gateway auth-token --show` and `openclaw dashboard`, since reaching the Control UI needs the shared token. Both are human guidance and are deliberately absent from the JSON, which carries the url and port. Two faults surfaced once a real start failed and are fixed here. A start that ended stopped rendered as a successful "stopped", wearing the mark `stop` earns; it now reports as having exited during startup. The message explaining why was dropped entirely for `start`, leaving a state word and nothing to act on; it is now shown whenever the gateway is not listening. That message named the gateway log by its path inside the session, which the user cannot open from the host, so it now names `clawctl collect-logs` instead. The two tests that asserted the path asserted a delivery mechanism rather than the behaviour; they now assert that the supervisor's reason and a usable route to the log both reach the user, and that the guest path does not. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: f472f437-3ee7-41f3-a501-81ae01590103
674eb68 to
b42b8bc
Compare
Impact
Makes
clawctl gateway-service startwait for an owned listener, narrate progress, and report an observed gateway port.Why This Change Was Made
A launched process is not necessarily a usable gateway. Startup now waits within a bounded, testable budget and reports only an unambiguous observed/configured port. It does not invent an HTTP URL because upstream TLS and Control UI base-path settings are not available here. Status reports a stopped gateway without mislabeling it as a startup failure.
Evidence
Validated at
b42b8bc:.\scripts\Test-DotNetQuality.ps1.\scripts\Test-NativeAotCli.Tests.ps1: 17 intended scenarios passed, including gateway narrationInstalled-package validation was not rerun because this review repair changes host-side endpoint classification and presentation; no local package was deployed.
Stack