Android recording cleanup stays pending after the recorder PID is reused
Maintainer thường phản hồi trong vòng 1 ngày
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- android, typescript
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Start an Android recording, then leave unfinished recording state after the native recorder exits, for example after a daemon interruption or a failed stop.
- Let Android reuse the recorded PID for an unrelated process while the recording's manifest and artifact remain.
- Close or recover that recording, entering
screenRecordingCleanupwith its valid persisted envelope. - Observe
cleanup-pending/transport-faileddespite 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-180identifies a PID whose command no longer matches asownership-lost; the replacement can be completely unrelated to recording.packages/platform-android/src/recording/chunks.ts:228-233throws immediately on that stop result, before any path-writer check.packages/platform-android/src/recording/cleanup.ts:17-27calls 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-263also throws when a poll establishes that the original process identity has terminated through reassignment.- Read
e41da2338fand itspackages/platform-android/src/recording/recovery-cleanup.test.tstest matrixdirect cleanup checks a reused PID and path writers when %s. Theemptycase 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.
- Ngôn ngữ chính
- TypeScript
- Star
- 5.3k
- Fork
- 377
- Merge trung bình
- 14 giờ 6 phút
- Pull request đã merge (30 ngày)
- 650
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của callstack/agent-device
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 79/100
callstack/agent-device#4249 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug ready-for-agent
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
callstack/agent-device#4212 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
iOS alert wait: the last poll can get ~30 ms and turns "no alert" into a failed readCó thể đã có người làm @pcbeingused333 đã nhận 6 ngày trước. Đang mởbug ready-for-agent
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
callstack/agent-device#4018 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
callstack/agent-device#1869 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug ready-for-agent
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
callstack/agent-device#4247 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của callstack/agent-device
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
"Claude Code request is missing its initial user message" when the prompt starts with an image pathĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
earendil-works/pi-claude-code#31 ·
Maintainer thường phản hồi trong vòng 8 ngày
-
bug pending triage
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
privatenumber/cleye#48 ·
-
Google text documents are base64-encoded twiceCó thể đã có người làm @feiiiiii5 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày