[Bug]: completed work wakes snoozed threads and breaks subsequent snoozing
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 23k
- Forks
- 5.9k
- Avg merge
- 11h 14m
- Merged PRs (30d)
- 357
Description
Before submitting
- I searched existing issues and did not find an exact duplicate.
- I included enough detail to reproduce or investigate the problem.
Summary
Snoozing an actively working thread does not reliably preserve the user’s chosen snooze state.
When the thread finishes working, it wakes itself immediately—even if its scheduled wake time has not arrived. If the user snoozes the thread again afterward, it may then fail to appear in the snoozed section of the sidebar.
The current behavior appears to conflate two independent state changes:
- the thread’s work finishing;
- the user’s snooze expiring or being explicitly cancelled.
Completion should not implicitly override an active snooze.
Area
Thread lifecycle / sidebar / snoozing
Steps to reproduce
- Start work in a thread and leave it actively running.
- Snooze the thread until a future time.
- Wait for the active turn to complete before the chosen wake time.
- Observe the thread’s sidebar state.
- Snooze the same thread again.
- Inspect the snoozed section of the sidebar.
Expected behavior
- The thread remains snoozed after its active turn completes.
- It wakes only when the selected snooze time arrives or the user explicitly unsnoozes it.
- Snoozing the thread again consistently places it in the snoozed section.
- The UI makes the thread’s state understandable: working status, completion status, and snooze status should not silently overwrite one another.
Actual behavior
- Completing the active turn wakes the thread immediately, regardless of the selected snooze time.
- After this automatic wake-up, snoozing the thread again may not move it into the snoozed section.
- The sidebar therefore presents state that does not correspond to either the user’s original snooze choice or their subsequent one.
Proposed state model
Snooze should be modeled as a user-controlled visibility or attention state, independent of execution state.
For example:
working → completedchanges execution state only.visible → snoozed-until(timestamp)changes attention state only.- Work completion may update the snoozed thread’s unread or completed indicator, but should not clear
snoozed-until. - Only expiration, explicit unsnoozing, or another clearly documented user action should clear the snooze.
- Re-snoozing should be idempotent and should always reconcile the thread into the snoozed sidebar collection.
If product intent is for completion to wake a thread, that behavior should be explicit when snoozing—for example, “Snooze until 3 PM or until this work finishes.” The current interface instead implies a time-based promise that completion silently breaks.
Impact
Snoozing is an attention-management action. When background completion overrides it, finished work unexpectedly returns to the active sidebar and interrupts the user’s chosen queue.
The second failure is more confusing: the user performs the same snooze action again, but the thread no longer appears where snoozed threads are expected to live. This makes it unclear whether the action succeeded, whether the thread is hidden elsewhere, or whether its state has become inconsistent.
Reproduction frequency
Observed repeatedly with a thread snoozed while an active turn was still working.
Environment
T3 Code desktop
Logs or supporting evidence
Not yet collected.
Related issues
Potentially related to #5377, which reports another lifecycle transition being deferred while a thread is snoozed.
This report covers a different sequence:
- an actively working thread is snoozed;
- work completion wakes it before the selected time;
- snoozing it again may fail to place it in the Snoozed section.
Both issues may originate from execution-state transitions and snooze-state transitions being applied independently without a single reconciled lifecycle model.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the thread lifecycle, snooze handling, and sidebar state reconciliation described in the reproduction steps. Reproduce completion before the wake time, then re-snooze the thread; done means completion preserves the snooze, expiration or explicit unsnoozing wakes it, and re-snoozing places it in the Snoozed section consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- desktop, frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100