Skip to content

Conversation

@mtopo27
Copy link
Contributor

@mtopo27 mtopo27 commented Nov 21, 2025

add amplitude events for size analysis pages

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

@linear
Copy link

linear bot commented Nov 21, 2025

@github-actions github-actions bot added the Scope: Frontend Automatically applied to PRs that change frontend components label Nov 21, 2025
@mtopo27 mtopo27 marked this pull request as ready for review November 21, 2025 22:04
@mtopo27 mtopo27 requested review from a team as code owners November 21, 2025 22:04
pageLinks={pageLinks}
organizationSlug={organization.slug}
projectSlug={projectSlug}
onRowClick={handleBuildRowClick}
Copy link
Contributor

Choose a reason for hiding this comment

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

Bug: hasSearchQuery prop always passes true instead of variable

The hasSearchQuery prop is written without a value, which in JSX always evaluates to true. This ignores the hasSearchQuery variable defined earlier that contains the actual search query state. The prop should be hasSearchQuery={hasSearchQuery} to pass the variable's value. This causes the table to always behave as if there's a search query, even when there isn't one.

Fix in Cursor Fix in Web

<LinkButton
to={buildUrl}
onClick={() =>
trackPreprodBuildAnalytics('preprod.builds.compare.go_to_build_details', {
Copy link
Member

@roggenkemper roggenkemper Nov 24, 2025

Choose a reason for hiding this comment

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

usually we avoid creating these specific track analytics functions if possible - if you search for trackAnalytics, you'll see that this generic function can work for analytics from any team

};

const handleConfirmDelete = () => {
handleDeleteArtifact();
Copy link
Member

Choose a reason for hiding this comment

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

Did we want analytics here?

organization,
build_id: build.id,
project_slug: projectId,
project_type: headBuildDetails.app_info?.platform ?? null,
Copy link
Member

Choose a reason for hiding this comment

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

Are both project_type and platform needed when they are both being set to a platform value?

const organization = useOrganization();
const {projectId} = useParams<{projectId: string}>();
const platform = headBuildDetails.app_info?.platform ?? null;
const projectType = headBuildDetails.app_info?.platform ?? null;
Copy link
Member

Choose a reason for hiding this comment

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

Same, is projectType == platform intentional? There's probably a context to fetch the current project we should be using?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah projectType is supposed to be the project.type, which is different from the platform, but we don't have that data available in the frontend currently. I'm going to drop it where its not available, and put up a linear ticket to eventually follow with that info. For the time being, it is reconstructible with project_slug + org so if we need to analyze it we can

platform: buildDetailsData.app_info?.platform ?? null,
build_id: buildDetailsData.id,
project_slug: projectId,
project_type: buildDetailsData.app_info?.platform ?? null,
Copy link
Contributor

Choose a reason for hiding this comment

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

Bug: Inconsistent project_type usage in analytics events

The project_type parameter is being set to platform values in two analytics events, contradicting the PR discussion where the maintainer stated they would drop project_type where it's not available. All other analytics events in this PR correctly omit project_type, but preprod.builds.details.delete_build and preprod.builds.release.build_row_clicked incorrectly set project_type to platform values instead of omitting it.

Additional Locations (1)

Fix in Cursor Fix in Web

platform: platformProp ?? null,
project_type: projectType,
source: 'metric_card',
});
Copy link
Contributor

Choose a reason for hiding this comment

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

Bug: Missing analytics parameters in build details events

Analytics events for preprod.builds.details.open_insights_sidebar, preprod.builds.details.expand_insight, and preprod.builds.details.open_insight_details_modal are missing build_id and project_slug parameters. These components don't receive or retrieve the build ID and project slug that are available in parent components, leading to incomplete analytics tracking. Other analytics events in the same PR (like in buildDetailsHeaderContent.tsx) include these parameters, showing the inconsistency.

Additional Locations (2)

Fix in Cursor Fix in Web

@mtopo27 mtopo27 merged commit 9a71d0b into master Nov 24, 2025
48 checks passed
@mtopo27 mtopo27 deleted the mtopo27/add-preprod-analytics-events branch November 24, 2025 18:44
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.

4 participants