Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Scheduling badge counts change requests that aren't scheduled

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#8,774 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@Abhipsita-coder đang làm issue này rồi.

Từ ngày 19/10/2026.

  • #8806 của @Abhipsita-coder — đang mở

Đá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
68/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

Dấu thời gian lỗi thời đến từ useRef(moment().toISOString()) tại frontend/web/components/navigation/navbars/EnvironmentNavbar.tsx:24, và cùng một mẫu xuất hiện ở useMemo(..., []) tại frontend/web/components/pages/ScheduledChangesPage.tsx:40. Bắt đầu bằng cách tái hiện huy hiệu với hai change request được commit ngay lập tức, sau đó tính live_from_after tại thời điểm yêu cầu được gửi đi. Hoàn thành khi huy hiệu vẫn trống sau khi commit mà không cần làm mới trang, và trang Scheduling vẫn chỉ liệt kê các thay đổi có ngày trong tương lai.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug front-end priority-customer
How are you running Flagsmith
  • SaaS at flagsmith.com
Describe the bug

The Scheduling item in the environment sidebar shows a count badge for change requests that were committed for immediate publish, not scheduled. The Scheduling page itself correctly shows no scheduled changes, and the badge clears on a page refresh.

Steps To Reproduce
  1. Enable change requests on an environment.
  2. Load the dashboard and leave the tab open.
  3. Create two change requests, approve and commit them, publishing immediately (no schedule).
  4. Look at Scheduling in the environment sidebar — it shows a 2 badge.
  5. Refresh the page — the badge disappears.
Expected behavior

No badge, as there are no scheduled changes.

Likely cause

frontend/web/components/navigation/navbars/EnvironmentNavbar.tsx:24 pins live_from_after to the time the navbar mounted:

const date = useRef(moment().toISOString())
const { data: scheduledData } = useGetChangeRequestsQuery({
  committed: true, environmentId, live_from_after: date.current, page_size: 1,
})

A change request published immediately gets a live_from of its commit time, which is after that pinned timestamp, so the list endpoint returns it and the badge counts it as scheduled. Committing invalidates the ChangeRequest LIST tag, so the query refetches — but with the same stale timestamp. A refresh re-mounts the navbar with a current timestamp, so the change request drops out.

frontend/web/components/pages/ScheduledChangesPage.tsx:40 pins the same value with useMemo(..., []), so a long-lived session on that page will drift the same way.

Computing live_from_after at request time rather than at mount, or filtering server-side on "live in the future", would both fix it.

Ngôn ngữ chính
Python
Star
6.6k
Fork
591
Merge trung bình
2 ngày 13 giờ
Pull request đã merge (30 ngày)
131

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Flagsmith/flagsmith

Tất cả issue của Flagsmith/flagsmith

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.