[Jacksondr5]

Problem

When expo-device-hub's device list reports errors, the Device panel's warning ("Device discovery warning · This machine") shows only each error's message. The device_list MCP tool gives agents the same text. The hub's error field, which holds the actual cause, is dropped.

This happened on my Mac when CoreSimulatorService stopped answering. Reproduced on main at 90c455ff8f (details under Verification), the warning reads only:

[apple-utils] Failed to run xcrun simctl list devices --json:

It stops at the colon. The cause the hub reported ("…Unable to connect to CoreSimulatorService…") never reaches the person or the agent, so neither can tell what went wrong.

Change

In apps/server/src/device/DeviceHubOperations.ts, the list path now appends the head of the hub's error after each warning's message. It applies to the warnings left after the existing filters (#25815's Android filter and the deleted-plist filter).

The hub's error is a util.inspect of Node's exec error: the error text, then Node's stack frames, then the inspected fields (code, killed, signal, cmd, stdout, stderr). I keep only the lines before the first stack frame, trimmed, with blank lines dropped and joined with a space. The stack and the inspected fields are dropped, so each warning stays one line in the plain-text banner.

Each warning is also capped at 2,000 characters as a backstop. That cap is the one the boot path already applies to its diagnostics. I moved it into a small helper that both paths use. The boot path's diagnostics are otherwise unchanged, since agents use them in full to recover. The filter for a deleted simulator's missing plist (ENOENT) is unchanged.

Scope and approval

This is a very small, focused fix for an obvious bug. The boot path in the same file already keeps both error.message and error.error, with the comment "Keep the hub's launch command and nested failure available to agents for recovery." The list path never got the same treatment. This PR does only that, and does not change the timeout message, the empty-list handling, or the hub request helper.

Verification

• New test in apps/server/src/device/DeviceService.test.ts, next to the existing discovery-warning test. It feeds two inspect-style hub errors, each with a stack and an inspected object: the simctl failure, and an avdmanager ENOENT on a host where Android is available. With Android unavailable, fix(server): Macs without Android no longer show avdmanager discovery warnings #25815 already hides [android-utils] warnings, and its own test covers that. The host detail is exactly these two lines, with no stack frames and no stderr::

  • [apple-utils] Failed to run `xcrun simctl list devices --json`: Error: Command failed: xcrun simctl list devices --json An error was encountered processing the command (domain=NSPOSIXErrorDomain, code=60): Unable to connect to CoreSimulatorService [xcrun shim fail mode]
  • [android-utils] Failed to run `avdmanager list avd`: Error: spawn /Users/test/Library/Android/sdk/cmdline-tools/latest/bin/avdmanager ENOENT

  The test fails on main, where the detail is just the two messages.

• vp test run apps/server/src/device/DeviceService.test.ts: 31 passed, including the existing deleted-plist, boot-diagnostics and Android-filter (fix(server): Macs without Android no longer show avdmanager discovery warnings #25815) tests.

• Lint, format and the server typecheck pass.

macOS 27.0.1, captured on main at 0894156d9a and this branch with the same setup. To fail simctl the way an unreachable CoreSimulatorService does without breaking the real one, the dev server's PATH had a fake xcrun that exits 1 with CoreSimulator's error (hence "[xcrun shim fail mode]" in the text):

Before (main): the warning stops at the colon.

After (this branch): the warning includes the cause.

Related problems are reported separately: a hung simctl gets the generic "Could not communicate with device support" timeout message and the list empties on a failed refresh (#25707), and expo-device-hub has no simctl timeout (expo/expo-device-hub#464).

Written by Claude Opus 5.5, in Claude Code inside J5 Code, on Jackson's behalf.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at b4a7f0c

Macroscope's review found this PR approvable — This focused fix preserves device discovery behavior while enriching existing warnings with bounded hub error details and adds targeted coverage for the formatting. The shared diagnostic cap is behaviorally unchanged for boot failures, with no schema, deployment, default, or static-analysis changes.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 0894156
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 718bb4e7-cbdd-44b8-a513-e9c8b045a1cc

Commits

Reviewing files that changed from the base of the PR and between b4a7f0c and c92e835.

Files selected for processing: 2

• apps/server/src/device/DeviceHubOperations.ts
• apps/server/src/device/DeviceService.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

Walkthrough

Device-list warnings now include concise hub error details before stack frames. Warning and boot-failure diagnostics use a shared 2,000-character limit. Tests verify that discovery warnings omit stack frames and stderr output.

Changes: Device diagnostics

Layer / File(s)	Summary
Diagnostic formatting and warning coverage apps/server/src/device/DeviceHubOperations.ts, apps/server/src/device/DeviceService.test.ts	Helpers extract trimmed error text before stack frames and cap diagnostic text at 2,000 characters. Device-list warning details include the extracted text. Boot-failure diagnostics use the shared cap helper. Tests check error causes and omission of stack frames and stderr.

Priority: Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related issues

• A hung simctl shows a network error, and the device list empties and refills #25707: The issue concerns the same device-list error path. This PR formats the discovery warning but does not change the timeout message or empty-list behavior.

Possibly related PRs

• pingdotgg/t3code#24027: Adds simctl discovery warnings to the same device-list flow.
• pingdotgg/t3code#25971: Changes device-list handling for timeouts and discovery failures. This PR formats the reported errors.

Suggested reviewers: juliusmarminge

Merge Risk: Minimal · up to c92e8

Device diagnostics retain the intended concise error details without introducing an actionable merge risk.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title follows the conventional commit format and names the main change: device list warnings now keep the hub's error detail. It matches the DeviceHubOperations.ts change, which appends the hub er…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Description check		The description follows the template's main sections: Problem, Change, Scope and approval, and Verification. It explains the bug clearly, with reproduction details and the affected warning text. The C…

Full details: Title check

Explanation

The title follows the conventional commit format and names the main change: device list warnings now keep the hub's error detail. It matches the DeviceHubOperations.ts change, which appends the hub error head to each warning, and the new discovery-warning test. The title is concise and specific.

Full details: Description check

Explanation

The description follows the template's main sections: Problem, Change, Scope and approval, and Verification. It explains the bug clearly, with reproduction details and the affected warning text. The Change section describes the behavior, the 2,000-character cap, and the shared helper. Verification lists a focused test, the exact command and result, lint/format/typecheck, and before/after screenshots. The Scope and approval section claims a very small, focused fix of an obvious bug and explains why it qualifies without a prior issue. It does not link a triaged issue or maintainer approval, and the template requires that link or an explicit exemption explanation. The author's exemption argument is reasonable, but the reviewer should confirm it. The description also reports 31 passing tests, while the PR objectives report 30, so the count needs a check. It also names the commit at which the bug reproduced, so the reviewer can verify the reproduction.

Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified unchanged head c92e835cb1e0542d10469411a294cc133c0bd30e against github/main at 8f1e61cc7f on linux. ran one background dev server at a time, with isolated state, real android sdk tools, and playwright using /usr/bin/google-chrome. created the project through the app and ran real codex gpt-6.1-sol turns that called device_list. no mocks, fixtures, or command shims.

the real sdk requires java 17, while this vm initially had java 11. SKIP_JDK_VERSION_CHECK=1 lets java report the actual class-version error to stderr. on main the panel warning ends at the colon. on this head both the device panel and the agent's device_list response include UnsupportedClassVersionError, class file version 61.0, and the runtime limit 55.0, without node stack frames or inspected fields.

nearby behavior: refresh remains usable, warning dismissal works, and switching the real java runtime to 17 then refreshing clears the warning. a fresh codex device_list call succeeds with an empty list, local host ready, and no discovery warnings.

short runtime transcript:

$ SKIP_JDK_VERSION_CHECK=1 avdmanager list avd  # java 11
Error: LinkageError occurred while loading main class com.android.sdklib.tool.AvdManagerCli
java.lang.UnsupportedClassVersionError: ... class file version 61.0 ... up to 55.0

$ avdmanager list avd  # after switching to java 17
Available Android Virtual Devices:

$ curl http://127.0.0.1:36933/api/devices
{"simulators":[],"emulators":[],"errors":[]}

blacksmith: 31 device-service tests passed. vp run check:changed HEAD^ passed format, lint, both knip passes, graphql validation, affected typechecks, and tests. used the explicit parent ref because the worker's shallow snapshot initially had no merge base with origin/main. existing github checks are green. no source changes or pushes were needed.

Not verified

macos core simulator failures, native ios/android clients, windows, remote/ssh hosts, physical devices, and device boot/streaming were not exercised here. this vm has no configured virtual or connected devices. the linux android discovery failure exercises the same changed warning path, but does not prove those platform-specific flows. the sdk's initial preflight-only java message is on stdout; this formatter intentionally drops inspected stdout fields and does not surface that separate message.