callstack / callstack/agent-device
Remote iOS recording: recover completed export after record stop times out
- Dominant language
- TypeScript
- Stars
- 4.6k
- Forks
- 299
- Avg merge
- 10h 17m
- Merged PRs (30d)
- 515
Description
## Problem
A customer running agent-device against an EAS-hosted remote iOS simulator reported that `record stop` timed out client-side after 90 seconds while the daemon continued exporting. The recording eventually became available, but they could not find a CLI command to retrieve it and fetched it manually through the daemon's `/artifacts` endpoint.
This leaves an agent unable to finish retrieving its recording through the normal CLI workflow even though the export succeeds.
## Environment and evidence
- Remote iOS simulator on EAS Simulator.
- Version baseline for this report: 0.20.10; exact client/daemon versions and recording options still need confirmation from the reporter.
- Customer-reported observation, not independently reproduced by us. The exact timeout transcript, session ID, export duration, and a minimal reproduction are not yet available. The customer has offered transcripts and diagnostics.
- We have not established which layer owns the 90-second timeout.
## Requested behavior
- Distinguish a failed export from an export that is still running when the client stops waiting.
- Provide a supported CLI recovery path to inspect export status and retrieve the completed daemon-managed recording after the original request times out, without starting another recording or manually calling HTTP endpoints.
- Give actionable recovery information in the timeout response, including a stable recording/export identifier if needed.
- Preserve normal session/tenant ownership checks on retrieval.
The exact command shape is open. The existing documented `artifacts` command lists provider-hosted artifacts (for example BrowserStack/AWS Device Farm); this request concerns a recording exported by the remote agent-device daemon.
## Related work
- #197 covered normal remote artifact retrieval; this is specifically recovery after the original export request times out.
- #2170 concerns a host recording lock after an ungraceful recorder kill. Here the daemon reportedly kept exporting and produced an artifact, so this is not known to be the same mechanism.
Contributor guide
Assessment
This issue has not been assessed yet.