chore(billing-platform): Add trial limits to package line items#325
chore(billing-platform): Add trial limits to package line items#325brendanhsentry wants to merge 2 commits into
Conversation
|
The latest Buf updates on your PR. Results from workflow ci / buf-checks (pull_request).
|
|
|
||
| // How many units are available for a PackageConfig during a subscription trial? For packages that are not eligible for trials, | ||
| // this field will be unset for all line items. | ||
| oneof trial_units { | ||
| bool is_unlimited_trial = 10; | ||
| uint64 num_trial_units = 11; | ||
| } |
There was a problem hiding this comment.
do we really need this? I think it would be a positive change to allow trials for any line item. Why would we want to restrict it and also have the package know about trials?
There was a problem hiding this comment.
i'll let brendan confirm but i think the intention is to store the exact amount of units an org gets when they trial a specific package, that needs to be limited to a specific amount based on the package. we need to store this info(the reserved quotas per category for a trial of a specific package) somewhere, not sure what the best place is
There was a problem hiding this comment.
I think it would be a positive change to allow trials for any line item.
Subscription trials have limited amounts of reserved quantity for each line item that users do not control. So when a subscription trial begins they get pre-determined reserved quantities for all line items. I needed a way to encode those specific limits in the code.
One option was to define these limits in the Engagement service, but that just felt like an extra file we'd need to update when launching a new line item. Defining it in the package proto also gives us the benefit of being able to enforce the fact that users can only trial specific plans (ie am3_business or am3_business_ent).
I'm ok with defining these trial limits as a constant in the engagement service for now and we can revisit later.
have the package know about trials?
From my perspective, the user is trialing a specific package (including its features, which we'll need to take into account at some point in the future) so it felt natural to include that as part of the package config.
| sentry_protos.billing.v1.common.v1.TieredPricingRate uncapped_rate = 9; | ||
|
|
||
| // How many units are available for a PackageConfig during a subscription trial? For packages that are not eligible for trials, | ||
| // this field will be unset for all line items. |
There was a problem hiding this comment.
i'm wondering if these fields now mean we cannot effectively inherit from dev to team to business packages, since we will need different trial units for team and business packages, and therefore have to redefine all line item configs
There was a problem hiding this comment.
I'm not sure I follow. Can we leave trial units empty on developer and just overwrite the values in business plans?
There was a problem hiding this comment.
this works fine as long as we only allow subscription trials for business, i thought we offer them for team plans as well which means we would need to define trial units differently for team/business packages.
3 participants
Define trial config amounts in packages. This will be used by the Engagement service to validate that a package is eligible to be used for subscription trials and to provide TrialConfigs to the create_trial API.