Android: snapshot helper exits without parseable output after a screen transition (still on 0.21.33)
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 45/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- android, react-native, typescript
调研方向
Start by tracing the Android snapshot helper’s persistent session and one-shot am instrument fallback, then inspect how instrumentation output and failures become COMMAND_FAILED. Reproduce snapshots immediately after a screen transition on the Android 36 Google ATD emulator and capture the instrumentation exit status and result bundle. Done means the intermittent failure is understood and addressed, with a regression check for the transition case.
由索引模型根据 Issue 内容生成。
描述
Summary
On an Android emulator in CI, snapshot intermittently fails because the snapshot helper exits without returning parseable output. The client gets COMMAND_FAILED with details.androidSnapshotHelperFailureReason: "Android snapshot helper failed before returning parseable output". It reproduces on 0.21.28 and 0.21.33, so the vanished-child fix in #3901 (0.21.31) did not remove it for us.
Environment
- Emulator:
system-images;android-36;google_atd;x86_64(API 36, Google ATD), in CI - Driven through
@e2e-dev/mobile0.12.4 (persistent snapshot-helper session, then the one-shotam instrumentfallback) - App: React Native (Expo)
| Run | agent-device | Helper versionCode | Result |
|---|---|---|---|
| A | 0.21.28 | 21028 | helper exit after 629 ms |
| B | 0.21.28 | 21028 | session returned truncated XML → force-kill → one-shot fallback exits after 947 ms |
| C | 0.21.33 | 21033 | persistent session didn't answer → instrumentation fallback failed (1022 ms, then 602 ms) |
Frequency: an A/B over the same suite gave 1 failing run of 5 on 0.21.33 and 1 of 3 on 0.21.28.
Repro shape
In the 0.21.33 failure, the step was an assertion polling snapshots right after a screen transition (a peer mention opened from the notifications list). Failure is intermittent, and the request logs also show it on repeated snapshots.
Evidence excerpts
Run A, 0.21.28:
command=snapshot; helper version=0.21.28; versionCode=21028
android_snapshot_helper_capture durationMs=629: failed before returning parseable output
request_failed code=COMMAND_FAILED: Android snapshot helper failed: ...
Run B, 0.21.28:
android_snapshot_helper_session_stop: forceKilled=true
android_snapshot_helper_session_fallback: "Android snapshot helper session returned truncated XML"
android_snapshot_helper_capture durationMs=947: failed before returning parseable output
request_failed code=COMMAND_FAILED
Run C, 0.21.33 (two requests):
helper version=0.21.33; versionCode=21033
persistent-session answered=false; instrumentation fallback failed
capture durations: 1022 ms and 602 ms
reason: Android snapshot helper failed before returning parseable output
request_failed code=COMMAND_FAILED
Logcat:
- In run C, the Android automation logcat shows
Force stopping com.callstack.agentdevice.snapshothelper ...: start instr, then the process start andUiAutomation: Initialized. NoFATAL EXCEPTION,AndroidRuntimeorNullPointerExceptionline follows. - The
adb logcat -d -b crashdump taken after the suite is empty (run C; runs A/B predate that dump). - So the artifacts show the helper exiting, but not an in-process exception.
Asks
- Is there a helper-side log, or a flag such as
--debug, that would record why the instrumentation exited (exit code, instrumentation result bundle, aINSTRUMENTATION_ABORTED/shortMsg)? Our host only records "failed before returning parseable output". - Could the one-shot fallback be retried once by agent-device itself when the persistent session has just been force-killed? In our logs, both paths fail inside the same ~1 s window right after a transition.
Related: #3901 (vanished-child NPE, 0.21.31), #3929 (persistent helper frozen on ColorOS; a different symptom).
- 主要语言
- TypeScript
- 星标
- 5.2k
- 派生
- 359
- 平均合并
- 12 小时 48 分钟
- 30 天内合并 PR
- 657
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
callstack/agent-device 的其他 Issue
-
A session bound to an Apple device rejects --device=<its own UDID>可能已有人在做 @zerone0x 于 1 天前认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 64/100
callstack/agent-device#3945 ·
维护者通常 1 天内回复
-
Limrun iOS fill reports success but drops non-ASCII text可能已有人在做 @mvanhorn 于 7 天前认领。 未关闭bug ready-for-agent
难度 2/5 1-3 小时 新手友好度 87/100
callstack/agent-device#3819 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
callstack/agent-device#1869 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
callstack/agent-device#3992 ·
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 62/100
callstack/agent-device#3987 ·
维护者通常 1 天内回复
查看 callstack/agent-device 的全部 Issue
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 82/100
scaleway/ultraviolet#7089 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 67/100
tencent-connect/dsh-qqbot#81 ·
维护者通常 1 天内回复
-
[Bug]: Pen taps on sidebar rows start a drag and lose their click可能已有人在做 @makhnatkin 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 66/100
clangd/vscode-clangd#1009 ·