refactor(sessions): Part 1 - store actor & plumbing - #744

crates/minimald/src/sessions.rs (1)

318-339: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

A single undeletable orphan Pending record fails the entire daemon startup.

handle.delete().await? propagates any failure straight out of reap_orphan_pending and then out of Manager::init — so one Pending session whose on-disk delete fails (permission issue, read-only mount, etc.) blocks the daemon from starting at all, even though every other session is fine. The SubmitVerdict resume-failure branch a few hundred lines down (657-668) already establishes the "best-effort delete + log a warning, don't fail the caller" pattern for the same class of problem — worth applying the same resilience here.

🛡️ Suggested fix: don't let one failed delete abort the whole reap pass

    async fn reap_orphan_pending(store: &StoreHandle) -> Result<(), std::io::Error> {
        let mut reaped = 0u64;
        for handle in store.handles().await? {
            if handle.record().await?.status == sessions::SessionStatus::Pending {
                let id = *handle.id();
                if let Err(e) = handle.delete().await {
                    tracing::warn!(
                        session_id = %id,
                        error = %e,
                        "failed to reap orphan Pending session on startup; will retry next startup",
                    );
                    continue;
                }
                tracing::info!(
                    session_id = %id,
                    "reaped orphan Pending session on startup",
                );
                reaped += 1;
            }
        }
        if reaped > 0 {
            tracing::info!(count = reaped, "orphan Pending reap complete");
        }
        Ok(())
    }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/minimald/src/sessions.rs` around lines 318 - 339, Update
Manager::reap_orphan_pending to handle each handle.delete() failure locally: log
a warning with the session ID and error, then continue reaping remaining
sessions instead of propagating the deletion error. Only increment the reaped
count and emit the success log after a successful deletion; preserve propagation
of errors from listing handles or reading records.