Scheduling badge counts change requests that aren't scheduled
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 68/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- react, typescript
- 領域
- frontend
調査の方向性
古いタイムスタンプは frontend/web/components/navigation/navbars/EnvironmentNavbar.tsx:24 の useRef(moment().toISOString()) が原因で、同じパターンが frontend/web/components/pages/ScheduledChangesPage.tsx:40 の useMemo(..., []) にもあります。まず、すぐにコミットされた change request を 2 件作成してバッジを再現してください。そのうえで、リクエストを行う時点で live_from_after を計算します。完了の条件は、コミット後にページを再読み込みしなくてもバッジが空のままであることと、Scheduling ページに今後の日付の変更だけが表示され続けることです。
索引モデルが issue の本文から書いたものです。
説明
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
- Enable change requests on an environment.
- Load the dashboard and leave the tab open.
- Create two change requests, approve and commit them, publishing immediately (no schedule).
- Look at Scheduling in the environment sidebar — it shows a
2badge. - 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.
- 主要言語
- Python
- スター
- 6.6k
- フォーク
- 584
- 平均マージ
- 2日 13時間
- マージ済み PR（30日）
- 131
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
Flagsmith/flagsmith のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
Flagsmith/flagsmith#8681 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Flag dependency needs user documentation対応中かも @emyller が 11 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
Flagsmith/flagsmith#8524 · コメント 1 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
influx_query_manager doesn't catch ApiException, so Influx error responses 500対応中かも @siddiqueirshad が 26 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
Flagsmith/flagsmith#8510 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
Flagsmith/flagsmith の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 79/100
SACGF/variantgrid#2341 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 2 日以内に返信
-
comp/cli P3 type/security
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
NousResearch/hermes-agent#141420 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
CKV_GCP_18 (GKEPublicControlPlane) passes when master_authorized_networks_config is absent, control plane is internet-reachable対応中かも @Varshith-Kali が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
bridgecrewio/checkov#7753 ·
メンテナーはふだん 1 日以内に返信