ref(feedback): Refactor feedback query keys

[ryan953]

We can call apiOptions now and to more easily get what we need to make infinite items requests for the feedback list, and the call to see if there are new items for the top of the list.

This PR removes listQueryKey and listPrefetchQueryKey from the <FeedbackQueryKeysProvider> because we can just grab the options/keys on demand where we need them.
I've also switched over to useQuery and useInfiniteQuery calls, along with updating the cache entries.

The cache management part is the hardest to update. There's lots of generics when we use the raw queryClient.* methods, so types aren't a reliable safeguard imo

[ryan953]

The idea here is that we have stored a timestamp listHeadTime into react context when we first load the page and start the infinite list going.
We can scroll down the list and load more older items incrementally. As we scroll we get things older and older.

That listHeadTime is used to fetch and see if there are any items that are newer, something appeared since we loaded the page. We're fetching with a timerange like between now(aka payload) and tomorrow. Then if we find something we can clear caches, and reset the top of the list to an updated timestamp.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

Autofix Details

Bugbot Autofix prepared fixes for both issues found in the latest run.

• ✅ Fixed: Prefetch query missing limit: 1 constraint
  • Added limit: 1 to the prefetch return value to ensure only one item is fetched for polling instead of a full page.
• ✅ Fixed: Optional chaining makes loadedRows potentially undefined
  • Removed optional chaining from deduplicateItems call since it's a required prop, preventing potential runtime crashes on loadedRows.length access.

Or push these changes by commenting:

@cursor push 490af4b10c

Preview (490af4b10c)

diff --git a/static/app/components/infiniteList/infiniteListItems.tsx b/static/app/components/infiniteList/infiniteListItems.tsx
--- a/static/app/components/infiniteList/infiniteListItems.tsx
+++ b/static/app/components/infiniteList/infiniteListItems.tsx
@@ -54,7 +54,7 @@
   queryResult,
 }: Props<ListItem, Response>) {
   const {data, hasNextPage, isFetchingNextPage, fetchNextPage} = queryResult;
-  const loadedRows = deduplicateItems?.(data?.pages ?? []);
+  const loadedRows = deduplicateItems(data?.pages ?? []);
   const parentRef = useRef<HTMLDivElement>(null);
 
   const rowVirtualizer = useVirtualizer({

diff --git a/static/app/utils/feedback/coaleseIssueStatsPeriodQuery.tsx b/static/app/utils/feedback/coaleseIssueStatsPeriodQuery.tsx
--- a/static/app/utils/feedback/coaleseIssueStatsPeriodQuery.tsx
+++ b/static/app/utils/feedback/coaleseIssueStatsPeriodQuery.tsx
@@ -38,7 +38,7 @@
     const intervalMS = ONE_DAY_MS;
     const start = new Date(listHeadTime).toISOString();
     const end = new Date(listHeadTime + intervalMS).toISOString();
-    return statsPeriod ? {start, end, statsPeriod: undefined} : undefined;
+    return statsPeriod ? {limit: 1, start, end, statsPeriod: undefined} : undefined;
   }
 
   const intervalMS = intervalToMilliseconds(statsPeriod ?? '');

_{This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.}

[cursor]

Prefetch query missing limit: 1 constraint

High Severity

The coaleseIssueStatsPeriodQuery function's prefetch path no longer includes limit: 1 in its returned query. This causes the polling query for new feedback items to fetch a full page of results instead of a single item, increasing unnecessary load. An existing test confirms limit: 1 is expected.

 

^{Reviewed by Cursor Bugbot for commit 32f3553. Configure here.}

[ryan953]

yup. moved to the caller

[cursor]

Cursor Bugbot has reviewed your changes and found 3 potential issues.

There are 4 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 44e0719. Configure here.}

[cursor]

statsPeriod not stripped from query when falsy

Medium Severity

When statsPeriod is falsy, the function returns {} which doesn't override the statsPeriod value from listQueryState. The old code always destructured statsPeriod out of queryView, ensuring it never reached the API. Now, statsPeriod: null from page filters leaks into the query parameters. The code comment explicitly warns that the issues endpoint cannot handle empty statsPeriod values.

 

^{Reviewed by Cursor Bugbot for commit 44e0719. Configure here.}

[ryan953]

not important. we're doing statsPeriod ? so if it's falsey we don't need to override it really, it becomes an empty string at worst and still ignored.

[sentry]

Bug: The enabled condition for the useFeedbackHasNewItems hook always evaluates to false because it checks for statsPeriod in the query key, which is stripped out during key construction.
_{Severity: HIGH}

Suggested Fix

The logic for the enabled flag should be changed. Instead of checking for statsPeriod within the parsed query key, which will always be undefined, the logic should revert to a check similar to the previous implementation. For example, check if listPrefetchQueryKey is defined, as it will only be undefined for absolute date ranges where polling is not intended. This will correctly enable polling for relative date ranges.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: static/app/components/feedback/useFeedbackHasNewItems.tsx#L24-L29

Potential issue: A refactoring in `useFeedbackHasNewItems` introduced a logic error that
disables polling for new feedback items. The `enabled` condition now checks for the
`statsPeriod` property within the query key. However, the `stripUndefinedValues`
function removes this property before the query key is constructed. As a result, the
condition `statsPeriod && !foundData` always evaluates to `false`, preventing the
polling request from ever being made. This means users will never see the "Load new
feedback" banner, even when new items are available and a relative date range is
selected.