Skip to content

fix(device): a start that got no answer says a session may still have… - #297

Merged
finalerock44 merged 1 commit into
devfrom
fix/failed-start-may-have-started
Nov 4, 2026
Merged

finalerock44 merged 1 commit into
devfrom
fix/failed-start-may-have-started

Conversation

@finalerock44

Copy link
Copy Markdown
Contributor

… started

dcd device start printed a bare error when POST /device/sessions got no answer (a network error) or a proxy's 502 in the API's place. The API may have created the session anyway, and it is billed while it runs, so running the command again could leave two.

When the outcome is unknown, the error now says so first and lists the open sessions started in the last 2 minutes (the one in the --json envelope's session when there is exactly one), with how to check or stop them, or says it is safe to start again. The API's own errors (its { statusCode, message } envelope) still come through unchanged: those are refusals made before any session exists.

The recent-session lookup moves into DeviceGateway.recentlyStarted, shared with the MCP bridge's explanation of a failed start_device.

What & why

Type of change

  • fix — bug fix
  • feat — new feature
  • perf — performance improvement
  • refactor — code change that's neither a fix nor a feature
  • docs — documentation only
  • chore / ci / build / test — tooling, no user-facing change
  • Breaking change (title has ! or PR notes a BREAKING CHANGE:)

Checklist

  • PR title follows the Conventional Commits format (see comment above)
  • pnpm lint passes
  • pnpm typecheck passes
  • pnpm build passes
  • I have not bumped the version or edited CHANGELOG.md (release-please handles this)
  • I have signed the CLA (the bot will prompt on first contribution)
  • Docs / README.md / STYLE_GUIDE.md updated if behaviour or output changed

How to test

… started

`dcd device start` printed a bare error when POST /device/sessions got no
answer (a network error) or a proxy's 502 in the API's place. The API may
have created the session anyway, and it is billed while it runs, so running
the command again could leave two.

When the outcome is unknown, the error now says so first and lists the open
sessions started in the last 2 minutes (the one in the --json envelope's
session when there is exactly one), with how to check or stop them, or says
it is safe to start again. The API's own errors (its { statusCode, message }
envelope) still come through unchanged: those are refusals made before any
session exists.

The recent-session lookup moves into DeviceGateway.recentlyStarted, shared
with the MCP bridge's explanation of a failed start_device.
@finalerock44 finalerock44 self-assigned this Nov 4, 2026
@claude

claude Bot commented Nov 4, 2026

Copy link
Copy Markdown

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

🤖 Generated with Claude Code

@finalerock44
finalerock44 merged commit 7015a77 into dev Nov 4, 2026
9 checks passed
@finalerock44
finalerock44 deleted the fix/failed-start-may-have-started branch November 4, 2026 13:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant