Found on a Sunday, fixed on a Sunday — for the ones who work on Sundays only!
What happened
On Sundays, the snooze menu offers two rows that wake the thread at the exact same moment:
- Tomorrow —
9:00 AM
- Next week —
Mon 9:00 AM
"Next week" is defined as next Monday 9:00 AM, and on a Sunday "tomorrow" is Monday. Two labels, one instant.
Reproduction steps
- Have a settled thread in the sidebar (any project).
- Wait for a Sunday. 🙂 (Or trust the pinned unit test:
localDate(2026, 8, 30, 7, 1) — Sunday, 07:01.)
- Hover the thread row, open the snooze menu (clock icon).
- Observe five options, two of which point at the same wake time.
Expected
Four options. When two presets resolve to the same wake time, the menu offers one of them — "Tomorrow" is the natural label for the next day.
Actual
Five options, with a duplicated wake target:
| Option |
Wake time |
| In 1 hour |
8:01 AM |
| In 3 hours |
10:01 AM |
| This evening |
6:00 PM |
| Tomorrow |
9:00 AM |
| Next week |
Mon 9:00 AM ← same instant as Tomorrow |
Impact
Every user, every Sunday, on every client: web sidebar popover, web context menus, the chat-header action menu, and mobile native snooze menus all read the same shared preset list. Small, but it makes the menu look broken on the one day most people see it — and implies "Next week" means something different than it does.
Root cause
resolveSnoozePresets in packages/client-runtime/src/state/threadSettled.ts unconditionally appends both calendar presets. On Sunday, daysUntilMonday === 1, so nextWeek and tomorrow are the same instant.
Suggested fix
Only append "Next week" when it lands on a different instant than "Tomorrow" — a one-line guard in the shared builder, so every surface (web + desktop + mobile) inherits the fix with no per-client changes. Covered by a unit test pinning Sunday 2026-08-30.
Screenshots
Sunday menu from a live dev environment (project names redacted):
Live reproduction, before and after the one-line guard:
| Before |
After |
 |
 |
Found on a Sunday, fixed on a Sunday — for the ones who work on Sundays only!
What happened
On Sundays, the snooze menu offers two rows that wake the thread at the exact same moment:
9:00 AMMon 9:00 AM"Next week" is defined as next Monday 9:00 AM, and on a Sunday "tomorrow" is Monday. Two labels, one instant.
Reproduction steps
localDate(2026, 8, 30, 7, 1)— Sunday, 07:01.)Expected
Four options. When two presets resolve to the same wake time, the menu offers one of them — "Tomorrow" is the natural label for the next day.
Actual
Five options, with a duplicated wake target:
Impact
Every user, every Sunday, on every client: web sidebar popover, web context menus, the chat-header action menu, and mobile native snooze menus all read the same shared preset list. Small, but it makes the menu look broken on the one day most people see it — and implies "Next week" means something different than it does.
Root cause
resolveSnoozePresetsinpackages/client-runtime/src/state/threadSettled.tsunconditionally appends both calendar presets. On Sunday,daysUntilMonday === 1, sonextWeekandtomorroware the same instant.Suggested fix
Only append "Next week" when it lands on a different instant than "Tomorrow" — a one-line guard in the shared builder, so every surface (web + desktop + mobile) inherits the fix with no per-client changes. Covered by a unit test pinning Sunday 2026-08-30.
Screenshots
Sunday menu from a live dev environment (project names redacted):
Live reproduction, before and after the one-line guard: