Usage-limit banner hides the snooze action when snooze and auto-resume are both armed
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 78/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- react, typescript
- Lĩnh vực
- frontend
Hướng nghiên cứu
Bắt đầu với apps/web/src/components/chat/UsageLimitRecoveryBanner.tsx và so sánh trạng thái kết hợp giữa snooze và tự động tiếp tục của nó với apps/mobile/src/features/threads/UsageLimitRecoveryCard.tsx. Kiểm tra cách banner web tính snoozed dựa trên snoozedUntil và thời điểm đặt lại. Hoàn thành khi trạng thái kết hợp cung cấp hành động cho trạng thái snooze và sau khi thời điểm tiếp tục đã qua, banner lại cung cấp “Snooze until reset”.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Honest context
This is a follow up to #21384, which was closed as not planned. That closing was about the bigger ask (per-thread snooze and resume choices carrying over to later limits). I accept that part and will take it to Ideas if I want it.
This issue is only about the banner itself. Julius looked at the screenshot below and said the banner should have a snooze button as well, and that it looks like a bug. So I am filing this as a separate, narrow bug.
What the screenshot shows
A thread hit the Claude 5-hour usage limit. The banner reads "Usage limit reached, Resets 10/19/2026, 8:50:00 AM" and shows only "Cancel auto-resume". There is no "Snooze until reset" button and no "Wake now" button, even though the thread has both snooze and resume armed for this reset.

Why this is a bug, from the code
In apps/web/src/components/chat/UsageLimitRecoveryBanner.tsx, "Cancel auto-resume" showing means scheduled is true. The Snooze button renders only when snoozed is false, so its absence means the banner computed snoozed as true: the thread has both snooze and resume armed for this reset. In that combined state the web banner offers nothing for the snooze half.
Mobile disagrees with web here. The same state in apps/mobile/src/features/threads/UsageLimitRecoveryCard.tsx renders a "Wake now" button, so web is the inconsistent one.
On top of that, the snoozed check compares snoozedUntil to the reset time with no clock check. Timer wakes never clear snoozedUntil on the server, so after the reset passes the banner can keep treating the thread as snoozed and the button never comes back for that cycle.
Expected
When both snooze and resume are armed, the banner should still show a snooze state action (matching mobile's "Wake now"), and once the wake time has passed it should stop treating the thread as snoozed so "Snooze until reset" is offered again.
- Ngôn ngữ chính
- TypeScript
- Star
- 24.8k
- Fork
- 6.4k
- Merge trung bình
- 4 giờ 17 phút
- Pull request đã merge (30 ngày)
- 487
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của pingdotgg/t3code
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
pingdotgg/t3code#21107 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: ManagedOOMPreference=avoid in t3code.service puts systemd --user into a 100% CPU loop with uresourced (Fedora/GNOME)Có thể đã có người làm @nateEc đã nhận 2 ngày trước. Đang mởaccepted bug via-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 69/100
pingdotgg/t3code#20931 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: Every test run leaves a temp folder behind (vitest 5.0.1 via vite-plus 1.0.0)Có thể đã có người làm @Lenoridev đã nhận hôm nay. Đang mởbug via-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
pingdotgg/t3code#20128 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: T3_CODE_ORCHESTRATION_INSTRUCTIONS has no carve-out for user- or repo-mandated CLI review workflows (unlike T3_CODE_BROWSER_TOOL_INSTRUCTIONS)Có thể đã có người làm @nivethass15102007-tech đã nhận 4 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
pingdotgg/t3code#19908 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: Terminal pane's floating action toolbar covers the terminal's first lineCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mởaccepted bug via-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
pingdotgg/t3code#19536 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của pingdotgg/t3code
Issue tương tự
-
e2e-failure ready-to-code
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
redhat-developer/rhdh-plugin-export-overlays#4460 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
Maintainer thường phản hồi trong vòng 1 ngày
-
docs(api): openapi.yaml still documents gif-tools optimize colors as 2-256 instead of 2, 4, 16, 256Đang mởarea: backend documentation priority: low
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
snapotter-hq/SnapOtter#2919 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
obsidianmd/pele#39 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
biomejs/biome#12475 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày