Skip to content

feat(billing-platform): Add daily usage breakdown endpoint protos#321

Open
skonves wants to merge 2 commits into
mainfrom
stevekonves/reveng-188-daily-usage-breakdown
Open

feat(billing-platform): Add daily usage breakdown endpoint protos#321
skonves wants to merge 2 commits into
mainfrom
stevekonves/reveng-188-daily-usage-breakdown

Conversation

@skonves

@skonves skonves commented Jun 18, 2026

Copy link
Copy Markdown
Member

Adds two new endpoint protos used by the REVENG-188 platform CSV export work.

  • ChargeService.GetDailyUsageBreakdown — customer-facing presentation endpoint keyed by DataCategory for rendering usage CSVs.
  • UsagePricerService.GetDailyBreakdown — internal endpoint keyed by line_item_uid that evaluates each package's BillableMetric expression 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 to DataCategory for the customer-facing CSV.

Refs REVENG-188

@skonves skonves requested a review from a team as a code owner June 18, 2026 20:34
@linear-code

linear-code Bot commented Jun 18, 2026

Copy link
Copy Markdown

REVENG-188

@github-actions

github-actions Bot commented Jun 18, 2026

Copy link
Copy Markdown

The latest Buf updates on your PR. Results from workflow ci / buf-checks (pull_request).

BuildFormatLintBreakingUpdated (UTC)
✅ passed✅ passed✅ passed✅ passedJun 19, 2026, 12:56 AM

// 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 {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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.
@skonves skonves force-pushed the stevekonves/reveng-188-daily-usage-breakdown branch from 9763a64 to 5bfb1a8 Compare June 19, 2026 00:55

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Cursor Bugbot has reviewed your changes and found 2 potential issues.

Fix All in Cursor

❌ 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;
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

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.

Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit 2060a5f. Configure here.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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,

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

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.

Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit 2060a5f. Configure here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants