Android recording cleanup stays pending after the recorder PID is reused

未关闭
  • 哪里不对？
#4,242 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@thymikee 已经在做这个了。

开始于 2026年11月5日。

  • #4245 来自 @thymikee —— 未关闭

评估

难度
4/5
预计耗时
1-2 天
新手友好度
25/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
停滞
技术栈
android, typescript
领域
mobile, testing

调研方向

Read packages/platform-android/src/recording/chunks.ts and cleanup.ts, then inspect the Android recording transport fixture and recovery-cleanup.test.ts matrix referenced in the issue. Trace how ownership-lost and path-writer results affect cleanup. Done means cleanup succeeds for a reused PID with a conclusive empty writer scan, never signals the replacement process, and retains evidence when inspection is inconclusive or a writer remains.

由索引模型根据 Issue 内容生成。

描述

needs-triage

Problem

An Android recording can remain stuck in cleanup after its recorder has already exited. Android may assign that process number to another app or system process before the recording is closed or recovered. Cleanup treats that unrelated process as an unresolved recording owner and refuses to remove the old recording's files and marker. Retrying cleanup does not help while the replacement process remains alive. Users can be left with retained recording state and a device claim that cannot be released normally.

Reproduction path

  1. Start an Android recording, then leave unfinished recording state after the native recorder exits, for example after a daemon interruption or a failed stop.
  2. Let Android reuse the recorded PID for an unrelated process while the recording's manifest and artifact remain.
  3. Close or recover that recording, entering screenRecordingCleanup with its valid persisted envelope.
  4. Observe cleanup-pending / transport-failed despite the original recorder being gone and no process writing its artifact.

A deterministic host-only regression can use the existing Android recording transport fixture: return ownership-lost from stop and inspect for the persisted identity, and a conclusive empty writer scan for its path. Assert cleanup succeeds without signaling the replacement PID. This reproducer has not been executed here. PID reuse is an ordinary OS event, but its frequency in this exact cleanup window is uncertain.

Evidence

  • src/platform-runtime-screen-recording-android-host.ts:173-180 identifies a PID whose command no longer matches as ownership-lost; the replacement can be completely unrelated to recording.
  • packages/platform-android/src/recording/chunks.ts:228-233 throws immediately on that stop result, before any path-writer check.
  • packages/platform-android/src/recording/cleanup.ts:17-27 calls that stop routine and converts its exception into pending cleanup, so it never removes the old artifact or manifest.
  • packages/platform-android/src/recording/chunks.ts:257-263 also throws when a poll establishes that the original process identity has terminated through reassignment.
  • Read e41da2338f and its packages/platform-android/src/recording/recovery-cleanup.test.ts test matrix direct cleanup checks a reused PID and path writers when %s. The empty case proves cleanup without signaling the replacement; the inconclusive and foreign-writer cases correctly retain evidence. Admission-release and successor cases in that test depend on archive-only machinery and are not required for this issue.

Suggested minimal fix and completion conditions

In exact-evidence cleanup, distinguish termination of the original process from continued ownership of its numeric PID. When reassignment is confirmed, require a conclusive empty writer scan for the artifact before deleting it. Never signal the replacement process. Retain evidence if identity inspection or writer enumeration is inconclusive, or if any writer remains. Verify successful cleanup for a reused unrelated PID and refusal for a real path writer.

Estimated clean scope: roughly 40–80 production lines in Android recording chunks/cleanup, plus three or four focused transport-fixture cases. Do not port device-wide admission or change normal export behavior to implement this fix. Dependencies: none; main already exposes identity inspection and path-writer probing.

Relevant archive commit: e41da2338f0e3ff4663548df59c920cc78327daf. Its cleanup caller uses rollbackChunks through earlier archive changes; adapt the behavior to main's cleanupVerifiedAndroidEvidence rather than cherry-picking it unchanged.

Likelihood: plausible after delayed cleanup or daemon interruption on busy devices; uncommon in short uninterrupted recordings. Confidence: high in the cleanup failure, medium in practical incidence.

主要语言
TypeScript
星标
5.3k
派生
377
平均合并
14 小时 6 分钟
30 天内合并 PR
650

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

callstack/agent-device 的其他 Issue

查看 callstack/agent-device 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。