feat(billing): force global-views flag into PlanFeatures
#97148
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
Scope: Frontend
cvxluo
changed the title
PlanFeaturesPlanFeatures
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
![seer-by-sentry[bot]](https://avatars.githubusercontent.com/in/801464?s=60&v=4){kind=small}
Comment on lines
93
to
97
| for (const plan of plans) { | ||
| if (isBizPlanFamily(plan) || plan.id.includes('mm2')) { | ||
| plan.features.push('global-views'); | ||
| } | ||
| } |
There was a problem hiding this comment.
Potential bug: The code mutates a cached `plan.features` array by pushing `'global-views'` on every render, leading to duplicate entries over time.
- Description: The
useBillingConfighook caches plan data indefinitely due tostaleTime: Infinity. On each render of thePlanFeaturecomponent, the code iterates through plans and unconditionally pushes'global-views'into theplan.featuresarray. Because the plan objects are cached and shared across renders, this mutation occurs repeatedly on the same array reference. This leads to an accumulation of duplicate'global-views'entries, which can cause memory bloat and potential functional issues in downstream code that expects unique feature identifiers. - Suggested fix: Before pushing to the array, add a check to ensure the feature does not already exist. For example:
if (!plan.features.includes('global-views')) { plan.features.push('global-views'); }. This prevents duplicate entries from being added on subsequent renders.
severity: 0.45, confidence: 0.95
Did we get this right? 👍 / 👎 to inform future reviews.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
| // but since PlanFeature hooks into getsentry to determine which plan | ||
| // `global-views` is in, we need to hardcode it into the plans here | ||
| for (const plan of plans) { | ||
| if (isBizPlanFamily(plan) || plan.id.includes('mm2') || isAmEnterprisePlan(plan.id)) { |
There was a problem hiding this comment.
i believe isBizPlanFamily should already cover the mm2 plans that have global-views, but plan.id.includes('mm2') would also include plans that shouldn't have access
👍 made a ticket for myself here |
jarrettscott
approved these changes
Aug 12, 2025
andrewshie-sentry
pushed a commit
that referenced
this pull request
Aug 12, 2025
`PlanFeatures` takes a list of features and determines what plan has every one of those features. This is used in `powerFeatureHovercard`, which for a given feature, it shows a hovercard that says "Requires x plan", where x is the plan name from `PlanFeatures`. We wanted to move `global-views` to flagpole controlled, rather than getsentry (see getsentry/getsentry#17944), but since `PlanFeatures` reads from getsentry to determine what plan name to show, we ran into an issue where the plan name showed as 'unavailable' instead of 'business' (see #96947) To move `global-views` to flagpole controlled without having the hovercard break, we need `PlanFeatures` to know that `global-views` is a business feature. This _temporarily_ hard codes the feature into every business plan that `PlanFeatures` retrieves, so that we can safely remove the flag from getsentry. The motivation to have the flag in flagpole is so [this product change](https://sentry.slack.com/archives/C01N4L6SPT2/p1754414626890039) can be rolled out via the automator.
narsaynorath
added a commit
that referenced
this pull request
Aug 15, 2025
…7773) This forces the dashboards-edit and dashboards-basic feature flags to be associated to business and team plans even if they aren't returned by getsentry. This allows us to continue to indicate to the user what the next lowest plan the user needs to upgrade to for the feature. This is so we can migrate off of getsentry and move the flags into Flagpole to more easily switch the flags on when releasing logs. Builds off of #97148 which accomplishes the same thing but for `global-views` on different plans.
priscilawebdev
pushed a commit
that referenced
this pull request
Aug 25, 2025
`PlanFeatures` takes a list of features and determines what plan has every one of those features. This is used in `powerFeatureHovercard`, which for a given feature, it shows a hovercard that says "Requires x plan", where x is the plan name from `PlanFeatures`. We wanted to move `global-views` to flagpole controlled, rather than getsentry (see getsentry/getsentry#17944), but since `PlanFeatures` reads from getsentry to determine what plan name to show, we ran into an issue where the plan name showed as 'unavailable' instead of 'business' (see #96947) To move `global-views` to flagpole controlled without having the hovercard break, we need `PlanFeatures` to know that `global-views` is a business feature. This _temporarily_ hard codes the feature into every business plan that `PlanFeatures` retrieves, so that we can safely remove the flag from getsentry. The motivation to have the flag in flagpole is so [this product change](https://sentry.slack.com/archives/C01N4L6SPT2/p1754414626890039) can be rolled out via the automator.
priscilawebdev
pushed a commit
that referenced
this pull request
Aug 25, 2025
…7773) This forces the dashboards-edit and dashboards-basic feature flags to be associated to business and team plans even if they aren't returned by getsentry. This allows us to continue to indicate to the user what the next lowest plan the user needs to upgrade to for the feature. This is so we can migrate off of getsentry and move the flags into Flagpole to more easily switch the flags on when releasing logs. Builds off of #97148 which accomplishes the same thing but for `global-views` on different plans.
andrewshie-sentry
pushed a commit
that referenced
this pull request
Aug 26, 2025
…7773) This forces the dashboards-edit and dashboards-basic feature flags to be associated to business and team plans even if they aren't returned by getsentry. This allows us to continue to indicate to the user what the next lowest plan the user needs to upgrade to for the feature. This is so we can migrate off of getsentry and move the flags into Flagpole to more easily switch the flags on when releasing logs. Builds off of #97148 which accomplishes the same thing but for `global-views` on different plans.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PlanFeaturestakes a list of features and determines what plan has every one of those features. This is used inpowerFeatureHovercard, which for a given feature, it shows a hovercard that says "Requires x plan", where x is the plan name fromPlanFeatures. We wanted to moveglobal-viewsto flagpole controlled, rather than getsentry (see https://github.com/getsentry/getsentry/pull/17944), but sincePlanFeaturesreads from getsentry to determine what plan name to show, we ran into an issue where the plan name showed as 'unavailable' instead of 'business' (see #96947)To move
global-viewsto flagpole controlled without having the hovercard break, we needPlanFeaturesto know thatglobal-viewsis a business feature. This temporarily hard codes the feature into every business plan thatPlanFeaturesretrieves, so that we can safely remove the flag from getsentry. The motivation to have the flag in flagpole is so this product change can be rolled out via the automator.