Flag list not refreshed after status toggle/archive when flag.websiteId doesn't match the query key
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- typescript
- Domain
- frontend
Research direction
Start in apps/dashboard/app/(main)/websites/[id]/flags/_components/flags-list.tsx and compare the mutation invalidation keys with the websiteId used by page.tsx. Trace the route websiteId through FlagsList, FlagRow, StatusToggle, and FlagActions, then verify that toggling or archiving refreshes the visible list without a manual reload.
Written by the indexing model from the issue text.
Description
Bug
In apps/dashboard/app/(main)/websites/[id]/flags/_components/flags-list.tsx, both StatusToggle and FlagActions invalidate the flag list query after a successful mutation using:
queryClient.invalidateQueries({
queryKey: orpc.flags.list.key({
input: { websiteId: flag.websiteId ?? "" },
}),
});
But the page's list query is keyed with the route param (page.tsx):
useQuery({
...orpc.flags.list.queryOptions({ input: { websiteId } }), // websiteId = route param
});
oRPC / React Query invalidation matches keys element-wise. For any flag whose websiteId is null, the invalidation key carries websiteId: "" and never matches the cached entry — so after toggling or archiving a flag, the list keeps showing stale status until a manual page refresh.
Current reachability
Today this is latent: the flags page only lists website-scoped flags (the RPC list filter is eq(flags.websiteId, input.websiteId)), so every row has a matching websiteId. It becomes live as soon as:
- org-scoped flags are rendered in this component, or
- the list schema starts returning hybrid rows.
Suggested fix
Thread the real websiteId from the route into FlagsList → FlagRow → StatusToggle/FlagActions and use it for invalidation instead of flag.websiteId ?? "".
- Dominant language
- TypeScript
- Stars
- 1.2k
- Forks
- 216
- Avg merge
- 14h 53m
- Merged PRs (30d)
- 154
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from databuddy-analytics/Databuddy
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
databuddy-analytics/Databuddy#694 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
databuddy-analytics/Databuddy#666 · 1 comment ·
-
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
databuddy-analytics/Databuddy#649 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
databuddy-analytics/Databuddy#643 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
databuddy-analytics/Databuddy#638 · 2 comments ·
All issues in databuddy-analytics/Databuddy
Similar issues
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100