Keep thread storage available when diagnostic logs fail (#60466)

## Why

Failure to open the diagnostic logs database should not disable thread storage or database-only history listing. Thread deletion must still preserve saved conversations when diagnostic log cleanup cannot complete.

## What changed

- Allow state initialization to continue after non-corruption errors opening the logs database, while preserving corruption recovery.
- Report the original diagnostic database error after tracing is installed in the TUI and app server, and return it from log operations.
- Reject thread deletion before destructive cleanup when diagnostic storage failed to initialize.
- Continue periodic cleanup of legacy logs when the current logs database is unavailable.

## Testing

Extend coverage for unavailable log directories, database-only history listing, startup diagnostics, deletion preserving saved conversations, corrupt log headers, and periodic legacy log cleanup during a diagnostic storage outage.

GitOrigin-RevId: a5184580ae6c39ed0c4eefa8cb48ee7731a991c3
This commit is contained in:
Dmitriy Kovalenko
2026-11-09 23:22:08 +00:00
committed by copyberry
parent e1cc96712f
commit caae161dd0
11 changed files with 257 additions and 90 deletions
@@ -988,6 +988,13 @@ pub(super) async fn run_main_inner(
.with(otel_logger_layer)
.with(otel_tracing_layer)
.try_init();
if let Some(error) = state_db.as_ref().and_then(|db| db.diagnostic_logs_error()) {
tracing::warn!(
event.name = "diagnostic_database_unavailable",
error,
"diagnostic database unavailable"
);
}
if let Err(err) = screen_reader_result {
tracing::warn!("Could not save screen-reader detection: {err}");