Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Report the daemon host CPU architecture in /health

Đang mở
  • Có gì không ổn?
#3,047 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
75/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
node.js, typescript
Lĩnh vực
api, backend

Hướng nghiên cứu

Start at the existing /health handlers for the daemon and proxy, then trace how the proxy includes upstream health and how readRemoteDaemonHealth parses the response. Check the existing resolveMacRunnerArch behavior for architecture naming. Done means hostArch is reported and forwarded as specified, absent fields still parse, and the protocol check remains unchanged.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Purpose

A remote client cannot learn the CPU architecture of the host its simulators run on. Nothing in /health, devices --json, or eas simulator:get reports it.

Stim (appandflow/stim#1803) builds iOS simulator apps on one machine and installs them on a remote Mac's simulator through agent-device proxy or an EAS Simulator session. xcodebuild has no remote UDID at build time, so the build uses generic/platform=iOS Simulator, which forces ONLY_ACTIVE_ARCH=NO and compiles both arm64 and x86_64. On an Expo app that measured 285 s and a 341 MB .app, against 151 s and 172 MB with ARCHS=arm64. Knowing the host arch lets the client build one slice.

Observed on a real EAS Simulator session (daemon 0.21.16, client 0.21.12):

{"ok":true,"service":"agent-device-daemon","version":"0.21.16","rpcProtocolVersion":2}

agent-device devices --platform ios --json lists platform, appleOs, id, name, kind, target, booted, with no arch.

Required behavior

/health advertises an optional hostArch for the process that serves it, normalized to Apple arch names: Node x64 becomes x86_64, arm64 stays arm64, other values pass through. A proxy reports its own hostArch and the upstream daemon's inside upstream, as it already does for version.

{"ok":true,"service":"agent-device-proxy","version":"0.21.17","rpcProtocolVersion":2,"hostArch":"arm64",
 "upstream":{"ok":true,"service":"agent-device-daemon","version":"0.21.17","rpcProtocolVersion":2,"hostArch":"arm64"}}

The field is additive under ADR 0006 (a new optional response field older clients ignore), so rpcProtocolVersion stays 2. readRemoteDaemonHealth parses it when present and tolerates its absence.

Health is the right surface rather than device entries: arch is a property of the host, simctl does not report it per simulator, and a per-device field would cross discovery, the client normalizer, the output serializer and the MCP schema.

Known limit: the value is the arch the daemon's Node process runs as. An x64 Node under Rosetta on Apple silicon reports x86_64 while simulators boot arm64. resolveMacRunnerArch makes the same trade for the macOS runner destination.

Completion

  • curl <daemon>/health on an Apple silicon Mac includes "hostArch":"arm64".
  • Through agent-device proxy, both the proxy payload and upstream carry it.
  • A health payload without the field still parses, and the client's protocol check is unchanged.

Environment: macOS 27.0, Xcode 27.0, Node 22.22.2.

Ngôn ngữ chính
TypeScript
Star
4.8k
Fork
315
Merge trung bình
11 giờ 25 phút
Pull request đã merge (30 ngày)
545

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của callstack/agent-device

Tất cả issue của callstack/agent-device

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.