feat(billing-platform): Add daily usage breakdown endpoint protos#321
feat(billing-platform): Add daily usage breakdown endpoint protos#321skonves wants to merge 2 commits into
Conversation
|
The latest Buf updates on your PR. Results from workflow ci / buf-checks (pull_request).
|
| // work, the usage history table in the UI. Typical CSV downloads pass | ||
| // one contract; bulk operations (e.g. "download all" across a date | ||
| // range) may pass many to avoid N+1 calls. | ||
| message GetDailyUsageBreakdownRequest { |
There was a problem hiding this comment.
I don't think the charge service is the right place for this, probably Invoicer
Adds ``UsagePricerService.GetDailyBreakdown``, an internal endpoint that emits per-day, per-line-item ``UsageData`` (every outcome field, not just ``accepted``) for one or more contracts. Used by the REVENG-188 platform CSV export to back the existing legacy ``CustomerHistoryCsvResponder`` without re-implementing the ``BillableMetric.expression`` evaluator. Initial revision also added a ``ChargeService.GetDailyUsageBreakdown`` endpoint that translated UsagePricer's ``line_item_uid``-keyed output into ``DataCategory``-keyed rows for the customer-facing CSV. That translation has since moved to the getsentry web layer (where customer-facing rendering decisions like column naming and future i18n belong), so the Charge endpoint is dropped before this lands.
9763a64 to
5bfb1a8
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 2060a5f. Configure here.
| message GetDailyBreakdownRequest { | ||
| // The contracts whose daily breakdowns should be returned. | ||
| repeated string contract_ids = 1; | ||
| } |
There was a problem hiding this comment.
Contract IDs use wrong type
High Severity
GetDailyBreakdownRequest declares contract_ids as repeated string, while contract identifiers elsewhere in billing protos (including GetPriceForContractRequest and Contract metadata) are uint64. Callers and implementations that follow the established contract API will use the wrong wire type and field encoding for this request.
Reviewed by Cursor Bugbot for commit 2060a5f. Configure here.
There was a problem hiding this comment.
I kind of think we should start using string, we can always represent a uint64 as a string
| /// Credit-card orgs always support payg; invoiced orgs that should | ||
| /// support it are an explicit override. | ||
| #[prost(bool, tag = "8")] | ||
| pub supports_payg: bool, |
There was a problem hiding this comment.
Rust field missing proto source
Medium Severity
Generated BillingConfig in Rust adds supports_payg at tag 8, but billing_config.proto stops at month_interval (tag 7) with no supports_payg definition. Regenerating bindings from the committed protos drops this field, so Rust, Python, and the canonical proto schema disagree on BillingConfig.
Reviewed by Cursor Bugbot for commit 2060a5f. Configure here.


Adds two new endpoint protos used by the REVENG-188 platform CSV export work.
ChargeService.GetDailyUsageBreakdown— customer-facing presentation endpoint keyed byDataCategoryfor rendering usage CSVs.UsagePricerService.GetDailyBreakdown— internal endpoint keyed byline_item_uidthat evaluates each package'sBillableMetricexpression against raw usage.Two endpoints rather than one because they live at different service boundaries: UsagePricer owns expression evaluation and emits
line_item_uid; Charge translates that toDataCategoryfor the customer-facing CSV.Refs REVENG-188