Skip to content

Conversation

shayna-ch
Copy link
Member

@shayna-ch shayna-ch commented Oct 7, 2025

First PR in a series to refactor grouping info data structure (see linear issue).

Make front end accept and implement new grouping info data structure with grouping_config pulled out of individual grouping variants. Now the front end can accept either the correct new EventGroupingInfoResponse or the old EventGroupingInfoResponseOld which it will convert into the correct EventGroupingInfoResponse data type.

@github-actions github-actions bot added the Scope: Frontend Automatically applied to PRs that change frontend components label Oct 7, 2025
Copy link

codecov bot commented Oct 7, 2025

❌ 1 Tests Failed:

Tests completed Failed Passed Skipped
12144 1 12143 10
View the top 1 failed test(s) by shortest run time
useReplayCount getOne & hasOne should return 0 if the data is loaded but does not include a count for a requested id
Stack Traces | 0.236s run time
Error: expect(received).toBe(expected) // Object.is equality

Expected: 0
Received: undefined
    at Object.toBe (.../utils/replayCount/useReplayCount.spec.tsx:85:45)

To view more test analytics, go to the Test Analytics Dashboard
📋 Got 3 mins? Take this short survey to help us improve Test Analytics.

@shayna-ch shayna-ch changed the title old ref(groupingInfo): Refactor grouping info to avoid storing redundant data Oct 7, 2025
@shayna-ch shayna-ch requested a review from lobsterkatie October 7, 2025 23:27
@shayna-ch shayna-ch marked this pull request as ready for review October 7, 2025 23:45
cursor[bot]

This comment was marked as outdated.

Copy link
Member

@lobsterkatie lobsterkatie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! I assume you've tested sending both types of payloads?

Comment on lines +21 to +31
const grouping_config = old
? (
Object.values(old).find(
variant => 'config' in variant && variant.config?.id
) as any
)?.config?.id
: null;
return old
? {
grouping_config,
variants: old,
}
: null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit, totally not worth changing in this temporary function, but just an option to keep in mind. If you do an early out (if (!old), {return null;} as your first statement), then it'll save you from having to nest so deeply in the rest of the function, which will in turn make it easier to read.

Comment on lines 37 to 39
function isOld(
data: EventGroupingInfoResponseOld | EventGroupingInfoResponse | null
): boolean {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, more important in principle than in practice since this is all temporary, but if you make this a type predicate, then you won't have to do the casting in your groupInfoNew value below.

event: Event;
group: Group | undefined;
}): EventGroupingInfoResponse | null {
}): EventGroupingInfoResponseOld | EventGroupingInfoResponse | null {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you add groupingConfig: null to the return here, I think bugbot will stop yelling at you.

@shayna-ch shayna-ch marked this pull request as draft October 8, 2025 21:08
@shayna-ch shayna-ch force-pushed the shayna-ch/groupinginfo-fe-restructure-1 branch from cf9cf47 to bf44c8c Compare October 8, 2025 21:09
@shayna-ch shayna-ch marked this pull request as ready for review October 8, 2025 21:09
cursor[bot]

This comment was marked as outdated.

expect(screen.getByText('123')).toBeInTheDocument();
// Should not make grouping-info request
expect(groupingInfoRequest).not.toHaveBeenCalled();
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: Unnecessary API Mock in Local Data Test

The test "gets performance new grouping info from group/event data" mocks an API response for grouping info, then asserts the API call isn't made. Since performance grouping data is derived locally, this mock is unnecessary and creates a confusing contradiction in the test.

Fix in Cursor Fix in Web

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Scope: Frontend Automatically applied to PRs that change frontend components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants