Critical: Two completed sessions deleted unexpectedly, files completely removed

[hyper-charlie]

Summary

User reported that two fully transcribed and summarized sessions were completely deleted immediately after summarization, including all associated files and folders from the system.

Sessions Affected

1. [REDACTED] <> [REDACTED] — March 18, 2026
2. [REDACTED] <> [REDACTED] — March 18, 2026

Both sessions had been:

• Successfully recorded
• Fully transcribed
• Summarized before deletion

Observed Behavior

• Sessions disappeared from the Sessions folder in Hyprnote immediately after summarization
• Files and folders completely removed from filesystem (not in trash/recycle bin)
• User reports "Char deleted them" — unclear if accidental command or unexpected behavior

Expected Behavior

• Completed sessions should persist in the app and filesystem until explicitly deleted by user

Environment

• Platform: macOS 15.7.3 Sequoia (aarch64)
• App Version: 1.0.15
• Build: 2b111d3

Severity

Critical — data loss issue

Questions for Investigation

• Was there a command or action from Char (AI assistant) that triggered deletion?
• Possible race condition in session persistence or file deletion logic?
• Any relevant logs from the deletion timeframe?

[devin-ai-integration]

Investigation Findings

Most Likely Root Cause: isSessionEmpty race condition with the persister's empty-session-delete logic (PR #4620)

Commit bf41d14ba ("fix: avoid saving empty sessions", merged March 17) introduced a new code path in the session persister that automatically deletes session directories from disk when a session is considered "empty" at save time. This is the most recent and most relevant change — it was merged just one day before the reported data loss.

How It Works

There are three independent deletion paths that could cause this:

Path 1: Persister auto-delete of "empty" sessions (⚠️ highest suspicion)

In apps/desktop/src/store/tinybase/persister/session/changes.ts:38-91, every time the persister saves, it evaluates each changed session with isSessionEmpty(). If a session is deemed empty, buildEmptySessionDeleteOps generates a { type: "delete", paths: [...] } operation that removes the entire session directory from the filesystem via fs2Commands.remove() in collector.ts:234-246.

The race condition scenario:

1. Session finishes recording → transcripts exist in TinyBase store → session is NOT empty
2. Enhancer auto-triggers summarization (see EnhancerService.queueAutoEnhance in services/enhancer/index.ts:123-127)
3. Enhancement completes → the enhanced_notes row is updated → this triggers a persister save
4. During the save, isSessionEmpty checks tables.sessions?.[sessionId] — if by this point the TinyBase in-memory tables snapshot doesn't have the session row populated (e.g., it was transiently cleared or the tables snapshot is stale), isSessionEmpty returns true because !session → return true at line 40-42
5. The session directory is deleted from disk

The isSessionEmpty function in changes.ts operates on a TablesContent snapshot (from store.getTables()), not directly on the store. If the store state is mid-transaction or the tables snapshot doesn't reflect all related data, a fully-populated session could be incorrectly classified as empty.

Path 2: Tab-close empty session cleanup

In _layout.tsx:97-112, when a session tab is closed, isSessionEmpty (from store/tinybase/store/sessions.ts) is called. If it returns true, deleteSessionCascade is invoked which removes all session data from TinyBase AND calls fsSyncCommands.audioDelete() to remove audio files.

Path 3: Orphan cleanup

The persister runs orphan cleanup after every save (collector.ts:165-168). The session persister is configured to clean up directories under sessions/ whose IDs aren't in Object.keys(tables.sessions ?? {}). There's a safeguard (CLEANUP_SAFEGUARD_MIN_DISK_COUNT = 5, CLEANUP_SAFEGUARD_MIN_KEEP_RATIO = 0.5) but if only 1-2 sessions were removed from the in-memory state, this safeguard wouldn't trigger.

Relevant Files

File	Role
apps/desktop/src/store/tinybase/persister/session/changes.ts	isSessionEmpty() for persister — decides if session dirs get deleted
apps/desktop/src/store/tinybase/persister/session/save/empty.ts	buildEmptySessionDeleteOps() — generates delete operations for "empty" sessions
apps/desktop/src/store/tinybase/persister/factories/collector.ts	Executes write/delete/cleanup operations; contains deleteFiles() and runOrphanCleanup()
apps/desktop/src/store/tinybase/store/sessions.ts	isSessionEmpty() for tab-close path
apps/desktop/src/store/tinybase/store/deleteSession.ts	deleteSessionCascade() — cascade delete from TinyBase + audio
apps/desktop/src/services/enhancer/index.ts	EnhancerService — auto-triggers enhancement after session ends
apps/desktop/src/routes/app/main/_layout.tsx	Wires up tab-close → empty check → cascade delete
crates/fs-sync-core/src/cleanup.rs	Rust-side orphan directory/file cleanup
crates/fs-sync-core/src/session.rs	delete_session_dir() — removes session directory from filesystem

Recent Related Commits

• bf41d14ba (Mar 17, 2026) — "fix: avoid saving empty sessions" — Introduced the persister-level auto-delete of empty session directories. This is the prime suspect.
• 65a1123d5 — "optimize session deletion with audio handling"
• 4463b94e7 — "multi-session selection and bulk delete in timeline"
• 0629fd3bf — "add handler to remove empty session on tab close"
• 574c643ca — "add undo delete toast and state management"

Recommended Investigation Steps

1. Add logging to isSessionEmpty in changes.ts to log when a session is classified as empty, including the session ID and the state of the tables snapshot at that moment.
2. Check whether tables.sessions[sessionId] row is present but has all-empty fields vs. being entirely absent when the persister save fires after enhancement completes.
3. Consider adding a guard in buildEmptySessionDeleteOps to skip deletion if the session has associated transcripts or enhanced notes in the tables, as a defense-in-depth measure.
4. Consider reverting bf41d14ba as a hotfix if more users report this issue, since it is the most likely cause and was merged very recently.

Additional Context Needed

• Are there app-level logs from the user's machine during the deletion timeframe? The Rust-side cleanup emits tracing::info and tracing::debug events for orphan removals.
• Was the user closing session tabs around the time of deletion? This would implicate Path 2 (tab-close cleanup).
• Were both sessions in the same folder or different folders? This could indicate whether orphan cleanup vs. per-session empty-delete is the culprit.

[hyper-charlie]

Additional Critical Details

User confirms no deletion command was issued.

Sequence of Events ([REDACTED] session)

1. Session notes were loaded and displayed in the app window
2. Notes completely disappeared — window switched to "new tab" state
3. Audio files also deleted simultaneously
4. Files are unrecoverable with Disk Drill — suggesting data was overwritten, not just moved

Severity Implications

• Not accidental user deletion
• Suggests automatic/background process is deleting or overwriting session data
• Data is irrecoverable — likely filesystem overwrite rather than just removal
• This is a critical data integrity issue

Questions for Dev Team

• Is there a background cleanup process that could be triggered after summarization?
• Could there be a file handle collision or overwrite issue?
• Are there any temp file operations happening immediately after summarization that could cause data loss?

User is understandably frustrated — this requires immediate investigation and potential rollback/recovery strategies.