fix(dev-cli): handle shared-port services in status command#1302
fix(dev-cli): handle shared-port services in status command#1302evan-claw wants to merge 1 commit intoKilo-Org:improvement/kiloclaw-dev-clifrom
Conversation
Services that share a port (auto-fix/db-proxy on 8792, kiloclaw/git-token on 8795) were each shown as 'running' when only one was active, producing false positives. Group services by port before checking. For shared ports, show an ambiguous indicator (yellow) with '(shared — cannot distinguish)' instead of falsely marking both services as running. For unique ports, behavior is unchanged. Adds status.test.ts with 3 tests covering shared-port grouping logic.
|
|
||
| describe('status: shared-port detection', () => { | ||
| test('identifies services that share a port', () => { | ||
| const portServices = services.filter(s => s.port && s.type !== 'infra'); |
There was a problem hiding this comment.
WARNING: These tests don't exercise the status() behavior that changed
Each test rebuilds the port-grouping map directly from services, so they still pass even if status.ts regresses to probing every service independently again. The shared-port fix in dev/cli/src/commands/status.ts needs at least one behavior-level assertion on the command output or isPortListening call pattern to prevent that regression.
Code Review SummaryStatus: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Other Observations (not in diff)N/A Files Reviewed (4 files)
Reviewed by gpt-5.4-20260305 · 144,913 tokens |
|
This Pull Request has been inactive for 30 days and will be closed in 7 days if no further activity occurs. Please update or close this PR if it is no longer relevant. |
|
This Pull Request has been closed due to inactivity. |
Problem
The
pnpm kilo statuscommand checks whether each service is running by probing its registered port. However, the service registry assigns the same port to multiple services:auto-fixanddb-proxykiloclawandgit-tokenWhen either process in a shared-port pair is running,
statusfalsely reports both services as running — producing false positives.Proof the Issue Is Real
The registry (
dev/cli/src/services/registry.ts) explicitly declares:auto-fix→ port 8792,db-proxy→ port 8792kiloclaw→ port 8795,git-token→ port 8795The old
status.tsiterates all port-having services and callsisPortListening(svc.port!)independently for each. Since both services in a shared-port pair resolve to the same port number, a single listening process causes both to show green.The existing
registry.test.tsalready documents these conflicts with aconsole.warn— confirming they are known and intentional in the registry.Proof This Is Not a Band-Aid
The port conflicts originate in upstream
wrangler.jsoncfiles. The registry correctly mirrors those configs. These services are not intended to run simultaneously (as noted in the registry test), so changing the ports would be incorrect.The status command is the presentation layer responsible for showing accurate information. It is the correct place to handle shared-port ambiguity — not the registry, and not the upstream wrangler configs.
What Changed
dev/cli/src/commands/status.ts(shared — cannot distinguish)instead of falsely marking each as independently running. When not listening, show each service as not running individually.dev/cli/test/status.test.ts(new)3 tests covering the shared-port grouping logic:
All 18 tests pass (15 existing + 3 new).
Addresses review comment: #1142 (comment)