pingdotgg / pingdotgg/t3code

[Bug]: completed work wakes snoozed threads and breaks subsequent snoozing

Open
#6,368 1 comment 0 reactions 0 assignees View on GitHub

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:

  1. the thread’s work finishing;
  2. 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
  1. Start work in a thread and leave it actively running.
  2. Snooze the thread until a future time.
  3. Wait for the active turn to complete before the chosen wake time.
  4. Observe the thread’s sidebar state.
  5. Snooze the same thread again.
  6. 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 → completed changes 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.