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

macOS: main-thread panic in tauri-runtime-wry 2.8.1 freezes Cap mid Instant recording; the crashed recording then can't be recovered or reuploaded

Đang mở
  • Có gì không ổn?
#2,606 2 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

@AatmanAJ đang làm issue này rồi.

Từ ngày 15/10/2026.

  • #2630 của @AatmanAJ — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
18/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
macos, rust, tauri
Lĩnh vực
build-system, desktop

Hướng nghiên cứu

The panic is in tauri-runtime-wry 2.8.1's handle_user_message, which is a dependency, so the upstream fix (tauri-apps/tauri#14805) is the real lever. Within Cap, the recovery gap lives in apps/desktop/src-tauri/src/lib.rs (load_upload_resume_candidate_at, around line 8644), upload/lifecycle.rs (retry_existing), and crates/recording/src/recovery.rs (RequiredTrackFailure handling). Done would mean a maintainer-agreed design for an Interrupted state and a manual Recover action, verified by the existing crashed_and_failed_projects test still passing and a new recovery test; this is design work, so discuss it before coding.

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

Mô tả

Description

About 45 minutes into an Instant-mode recording (window capture), Cap's main thread panicked and the app froze. Recording and segment upload both stopped at the moment of the panic. The process stayed alive with a frozen UI for about 5 hours, until I force-quit it.

After relaunch, the recording was marked Failed { error: "Recording crashed" }. Clicking Reupload shows "This recording isn't ready to upload yet", and the app offers no way forward. Yet every completed segment on disk was intact. The only damage was one in-progress trailing segment per track.

I think there are two separate problems here.

1. The panic (tauri-runtime-wry 2.8.1)
panic at tauri-runtime-wry-2.8.1/src/lib.rs:3572:38 thread='main': already mutably borrowed: BorrowError
   7: core::cell::panic_already_mutably_borrowed
   8: tauri_runtime_wry::handle_user_message
   9: tauri_runtime_wry::make_event_handler::{{closure}}
  10: <tao::platform_impl::platform::app_state::EventLoopHandler<T> as tao::platform_impl::platform::app_state::EventHandler>::handle_user_events
  11-14: objc2::exception::{try_no_ret, catch, ...}
  15: std::panic::catch_unwind
  16: tao::platform_impl::platform::observer::control_flow_end_handler
  17-28: <unknown>
  29: tao::platform_impl::platform::event_loop::EventLoop<T>::run
  30: tao::event_loop::EventLoop<T>::run
  31: cap_desktop_lib::run::{{closure}}
  • Line 3572 is the windows.0.borrow() in handle_user_message.
  • No Rust frame on the main thread's stack holds a borrow_mut() of the WindowsStore. That suggests the conflicting borrow came from another thread, which matches tauri-apps/tauri#15003 and #14801 (WindowsStore is a RefCell with unsafe impl Send/Sync). Upstream tightened this in tauri-apps/tauri#14805 (merged 2026-07-06). In tauri-runtime-wry 2.12.2 the unsafe impl Send/Sync for WindowsStore lines are gone.
  • Cap 0.6.0 and current main (bd14dcc) both still resolve tauri-runtime-wry 2.8.1.
  • I couldn't reproduce it, so please treat the cross-thread explanation as a likely cause, not a confirmed one.
  • In the ~90 seconds before the panic, nothing was logged except normal Segment uploaded successfully lines. pmset -g log shows no sleep or wake around that time, so I don't think this is #1055.
  • Follow-on problem: tao's catch_unwind (frame 15) catches the panic, so the process keeps running in a broken state. Because of that, the crash sentinel and recovery didn't run until I force-quit. Exiting, or at least stopping and finalizing the active recording, on a main-thread panic would have saved several hours here.
2. A crashed Instant recording can't be recovered or reuploaded

After relaunch:

  • load_upload_resume_candidate_at changes InProgress to Failed { error: "Recording crashed" } (lib.rs:8644).
  • retry_existing requires local_ready and InstantRecordingMeta::Complete (lifecycle.rs:993, :1013), so Reupload can never proceed.
  • The Instant recovery path refuses any Failed meta with RequiredTrackFailure (recovery.rs:1773). An app crash with intact tracks is therefore handled the same way as a real track failure such as "required audio failed".

On-disk state after the crash:

Track Completed segments Trailing entry Manifest
display 1286, all sizes match the manifest segment_1287 {duration: 0, is_complete: false} + segment_1287.m4s.tmp is_complete: false
audio 891, all sizes match the manifest segment_892 (same pattern) + .m4s.tmp is_complete: false

Concatenating init.mp4 with the completed segments and muxing them with ffmpeg plays the full 44:40 with audio.

A manual recovery that worked. These edits reproduce what a clean stop would have written:

  1. In each track: remove the trailing incomplete entry, move the .m4s.tmp out of the folder, and set is_complete: true and total_duration.
  2. In recording-meta.json: change Failed { error } to Complete { fps: 30, sample_rate: null }, and set sharing from upload.pre_created_video.
  3. In tauri-upload.json: set local_ready: true.

On relaunch, Cap resumed the segment upload by itself, to the original share link. It completed, and cloud verification returned a receipt with fullDecode: true, hasAudio: true and requiredAudioVerified: true. The server-side duration (2680.35 s) matches the local recording exactly.

Suggestion. crashed_and_failed_projects_never_become_automatic_upload_candidates (lib.rs:10730) shows that never uploading these automatically is intentional, and that makes sense. What's missing is a manual, user-initiated "Recover" for crashed Instant recordings:

  • Tell an app crash apart from a track failure, e.g. with a separate Interrupted state.
  • Trim the trailing in-progress segment.
  • Run the existing strict validation (collect_segment_events / validate_recovery_manifests).
  • Mark the recording Complete so that Reupload works.

At the very least, the Reupload dead end should explain what happened and offer to export the local copy.

Reproduction

Not reliably reproducible. Context:

  • Instant mode, window capture of a browser video-call window.
  • The panic came about 45 minutes into the recording, about 92 minutes into the app session. It was the second long Instant recording in a row in that session; the first, about 46 minutes, completed and uploaded fine.
  • Segments were uploading concurrently, as normal for Instant mode.
Additional Context
  • Cap version: 0.6.0
  • Operating system, version: macOS 27.0 (Darwin 27.0.0), Apple Silicon
  • Logs: the panic and backtrace are from cap-desktop.log and panics.log; full logs are available on request.
Ngôn ngữ chính
Rust
Star
23.2k
Fork
2k
Merge trung bình
1 ngày 6 giờ
Pull request đã merge (30 ngày)
127

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 CapSoftware/Cap

Tất cả issue của CapSoftware/Cap

Issue tương tự

Thêm issue về Rust

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.