-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Windows desktop reliability (logs) + onboarding bits #1797
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||
|---|---|---|---|---|---|---|---|---|
|
|
@@ -4,7 +4,7 @@ | |||||||
| use std::sync::Arc; | ||||||||
|
|
||||||||
| use cap_desktop_lib::DynLoggingLayer; | ||||||||
| use tracing_subscriber::{layer::SubscriberExt, util::SubscriberInitExt}; | ||||||||
| use tracing_subscriber::{Layer, layer::SubscriberExt, util::SubscriberInitExt}; | ||||||||
|
|
||||||||
| fn main() { | ||||||||
| #[cfg(debug_assertions)] | ||||||||
|
|
@@ -71,8 +71,11 @@ fn main() { | |||||||
| eprintln!("Failed to create logs directory: {e}"); | ||||||||
| }); | ||||||||
|
|
||||||||
| let file_appender = tracing_appender::rolling::daily(&logs_dir, "cap-desktop.log"); | ||||||||
| let (non_blocking, _logger_guard) = tracing_appender::non_blocking(file_appender); | ||||||||
| let info_file_appender = tracing_appender::rolling::daily(&logs_dir, "cap-desktop.log"); | ||||||||
| let (info_file_writer, _info_logger_guard) = tracing_appender::non_blocking(info_file_appender); | ||||||||
|
|
||||||||
| let errors_file_appender = | ||||||||
| tracing_appender::rolling::daily(&logs_dir, "cap-desktop-errors.log"); | ||||||||
|
|
||||||||
| let (otel_layer, _tracer) = if cfg!(debug_assertions) { | ||||||||
| use opentelemetry::trace::TracerProvider; | ||||||||
|
|
@@ -125,10 +128,19 @@ fn main() { | |||||||
| tracing_subscriber::fmt::layer() | ||||||||
| .with_ansi(false) | ||||||||
| .with_target(true) | ||||||||
| .with_writer(non_blocking), | ||||||||
| .with_writer(info_file_writer), | ||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right now WARN/ERROR events will still go to If the goal is truly “split logs” (and to avoid double I/O on hot paths), you can filter the info file layer down to
Suggested change
|
||||||||
| ) | ||||||||
| .with( | ||||||||
| tracing_subscriber::fmt::layer() | ||||||||
| .with_ansi(false) | ||||||||
| .with_target(true) | ||||||||
| .with_writer(errors_file_appender) | ||||||||
| .with_filter(tracing_subscriber::filter::LevelFilter::WARN), | ||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since |
||||||||
| ) | ||||||||
| .init(); | ||||||||
|
|
||||||||
| install_panic_hook(logs_dir.clone()); | ||||||||
|
|
||||||||
| #[cfg(debug_assertions)] | ||||||||
| sentry::configure_scope(|scope| { | ||||||||
| scope.set_user(Some(sentry::User { | ||||||||
|
|
@@ -143,3 +155,72 @@ fn main() { | |||||||
| .expect("Failed to build multi threaded tokio runtime") | ||||||||
| .block_on(cap_desktop_lib::run(handle, logs_dir)); | ||||||||
| } | ||||||||
|
|
||||||||
| fn install_panic_hook(logs_dir: std::path::PathBuf) { | ||||||||
| let prev = std::panic::take_hook(); | ||||||||
| let panics_log = logs_dir.join("panics.log"); | ||||||||
| std::panic::set_hook(Box::new(move |info| { | ||||||||
| let location = info | ||||||||
| .location() | ||||||||
| .map(|l| format!("{}:{}:{}", l.file(), l.line(), l.column())) | ||||||||
| .unwrap_or_else(|| "<unknown>".to_string()); | ||||||||
| let message = info | ||||||||
| .payload() | ||||||||
|
Comment on lines
+163
to
+168
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Prompt To Fix With AIThis is a comment left during a code review.
Path: apps/desktop/src-tauri/src/main.rs
Line: 159-164
Comment:
**`RUST_BACKTRACE` has no effect on `Backtrace::force_capture()`**
`std::backtrace::Backtrace::force_capture()` (used in the panic hook) always captures a backtrace regardless of the `RUST_BACKTRACE` environment variable — that is the point of `force_capture` vs `capture`. The env-var block therefore only affects the *default* Rust panic handler (`prev(info)` call at the end of the hook). This works as intended for the default handler, but the block is misleading and could be removed without changing what ends up in `panics.log`.
How can I resolve this? If you propose a fix, please make it concise. |
||||||||
| .downcast_ref::<&str>() | ||||||||
| .map(|s| (*s).to_string()) | ||||||||
| .or_else(|| info.payload().downcast_ref::<String>().cloned()) | ||||||||
| .unwrap_or_else(|| "<no message>".to_string()); | ||||||||
| let backtrace = std::backtrace::Backtrace::force_capture(); | ||||||||
| let thread = std::thread::current(); | ||||||||
| let thread_name = thread.name().unwrap_or("<unnamed>").to_string(); | ||||||||
| let timestamp = chrono::Utc::now().to_rfc3339(); | ||||||||
| let pid = std::process::id(); | ||||||||
|
|
||||||||
| write_panic_record( | ||||||||
| &panics_log, | ||||||||
| ×tamp, | ||||||||
| pid, | ||||||||
| &thread_name, | ||||||||
| &location, | ||||||||
| &message, | ||||||||
| &backtrace, | ||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Replacing Prompt To Fix With AIThis is a comment left during a code review.
Path: apps/desktop/src-tauri/src/main.rs
Line: 182
Comment:
**Synchronous file writer in async context**
Replacing `tracing_appender::non_blocking` with a direct `RollingFileAppender` makes every `tracing` call block the calling thread until the write is flushed to disk. Inside Tokio worker threads (recording pipeline, export, preview rendering) this can stall the runtime and introduce latency spikes. If the goal is to ensure no logs are dropped on Windows, consider keeping `non_blocking` but explicitly flushing the guard on shutdown, or using `tracing_appender::non_blocking` with `lossy = false`.
How can I resolve this? If you propose a fix, please make it concise. |
||||||||
| ); | ||||||||
|
|
||||||||
| tracing::error!( | ||||||||
| target: "cap_desktop_panic", | ||||||||
| location = %location, | ||||||||
| thread = %thread_name, | ||||||||
| message = %message, | ||||||||
| backtrace = %backtrace, | ||||||||
| "panic" | ||||||||
| ); | ||||||||
| eprintln!( | ||||||||
| "[cap-desktop panic] thread '{thread_name}' at {location}: {message}\nbacktrace:\n{backtrace}" | ||||||||
| ); | ||||||||
| prev(info); | ||||||||
| })); | ||||||||
| } | ||||||||
|
|
||||||||
| fn write_panic_record( | ||||||||
| path: &std::path::Path, | ||||||||
| timestamp: &str, | ||||||||
| pid: u32, | ||||||||
| thread_name: &str, | ||||||||
| location: &str, | ||||||||
| message: &str, | ||||||||
| backtrace: &std::backtrace::Backtrace, | ||||||||
| ) { | ||||||||
| use std::io::Write; | ||||||||
| let Ok(mut file) = std::fs::OpenOptions::new() | ||||||||
| .create(true) | ||||||||
| .append(true) | ||||||||
| .open(path) | ||||||||
| else { | ||||||||
| return; | ||||||||
| }; | ||||||||
| let _ = writeln!( | ||||||||
| file, | ||||||||
| "[{timestamp}] pid={pid} thread='{thread_name}' at {location}: {message}\n{backtrace}\n----" | ||||||||
| ); | ||||||||
| let _ = file.flush(); | ||||||||
| } | ||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AssertUnwindSafeon retry pathAssertUnwindSafeis correct here — caught panics returnErrand the export is abandoned rather than retried into potentially corrupted state. One thing worth double-checking: the retry inexport_video(withforce_ffmpeg: true) runs immediately after a panic in the GPU path. If the panic leaked an exclusive lock on a WGPU device or left a GPU command encoder in an open state, the retry (even on the software/ffmpeg path) may encounter those residual locks. If you see intermittent hangs on the retry leg during Windows testing, that would be the likely cause.Prompt To Fix With AI