Skip to content

Conversation

zyfy29
Copy link
Contributor

@zyfy29 zyfy29 commented Oct 3, 2025

Fixes: #3748.

Comment on lines 92 to 126
// UsageItem represents a single usage item in the enhanced billing platform report.
type UsageItem struct {
Date *string `json:"date"`
Product *string `json:"product"`
SKU *string `json:"sku"`
Quantity *float64 `json:"quantity"`
UnitType *string `json:"unitType"`
PricePerUnit *float64 `json:"pricePerUnit"`
GrossAmount *float64 `json:"grossAmount"`
DiscountAmount *float64 `json:"discountAmount"`
NetAmount *float64 `json:"netAmount"`
RepositoryName *string `json:"repositoryName,omitempty"`
// Organization name is only used for organization-level reports.
OrganizationName *string `json:"organizationName,omitempty"`
}

// UsageReport represents the enhanced billing platform usage report response.
type UsageReport struct {
UsageItems []*UsageItem `json:"usageItems,omitempty"`
}

// PremiumRequestUsageItem represents a single usage line item in premium request usage reports.
type PremiumRequestUsageItem struct {
Product string `json:"product"`
SKU string `json:"sku"`
Model string `json:"model"`
UnitType string `json:"unitType"`
PricePerUnit float64 `json:"pricePerUnit"`
GrossQuantity int `json:"grossQuantity"`
GrossAmount float64 `json:"grossAmount"`
DiscountQuantity int `json:"discountQuantity"`
DiscountAmount float64 `json:"discountAmount"`
NetQuantity int `json:"netQuantity"`
NetAmount float64 `json:"netAmount"`
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I used value types here for required fields. This follows a recent discussion at #3679 (comment), but doesn't match the existing type. I believe the old pattern happens everywhere, but it's better to refactor the one upon because they are too similar.

Copy link

codecov bot commented Oct 3, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.13%. Comparing base (233fe03) to head (a7f93a9).

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #3751      +/-   ##
==========================================
+ Coverage   91.11%   91.13%   +0.01%     
==========================================
  Files         187      187              
  Lines       16702    16734      +32     
==========================================
+ Hits        15218    15250      +32     
  Misses       1296     1296              
  Partials      188      188              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Collaborator

@gmlewis gmlewis left a comment

Choose a reason for hiding this comment

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

Thank you, @zyfy29!
One minor typo tweak, please, then we should be ready for a second LGTM+Approval from any other contributor to this repo before merging.

cc: @stevehipwell - @alexandear

@gmlewis gmlewis added the NeedsReview PR is awaiting a review before merging. label Oct 3, 2025
@zyfy29 zyfy29 requested a review from gmlewis October 3, 2025 13:40
Copy link
Collaborator

@gmlewis gmlewis left a comment

Choose a reason for hiding this comment

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

Thank you, @zyfy29!
LGTM.

@stevehipwell
Copy link
Contributor

@gmlewis similar to my comment on #3737 I'm not sure the usage of Org & User function suffixes works to convey the correct context. Even if this is accepted here, as it is consistent with the existing functions, it would be good to get some docs to cover a consensus on contextual naming.

// PremiumRequestUsageReportOptions specifies optional parameters
// for the enhanced billing platform premium request usage report.
type PremiumRequestUsageReportOptions struct {
UsageReportOptions
Copy link
Contributor

Choose a reason for hiding this comment

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

UsageReportOptions contains the Hour field. But we can't set it in the GetPremiumRequestUsageReportOrg according to the documentation:

Image

Maybe we should mention this in a comment.

@gmlewis
Copy link
Collaborator

gmlewis commented Oct 6, 2025

@gmlewis similar to my comment on #3737 I'm not sure the usage of Org & User function suffixes works to convey the correct context. Even if this is accepted here, as it is consistent with the existing functions, it would be good to get some docs to cover a consensus on contextual naming.

Naming is indeed hard, and if you have recommendations for better names, please create "Suggested Changes" feedback in your code review and we can all discuss them if necessary. Thank you, @stevehipwell!

@stevehipwell
Copy link
Contributor

@gmlewis my concern is that the naming in the current PR is correct in the context of the existing functions so I'm unsure if this PR is the correct place to suggest wholesale changes? If it is would we be pushing for the existing functions to be renamed too?

@gmlewis
Copy link
Collaborator

gmlewis commented Oct 6, 2025

@gmlewis my concern is that the naming in the current PR is correct in the context of the existing functions so I'm unsure if this PR is the correct place to suggest wholesale changes? If it is would we be pushing for the existing functions to be renamed too?

Oh, I see. Yes, I think we should proceed with this PR and can you please open a new issue proposing widespread wholesale change recommendations, @stevehipwell ?

@stevehipwell
Copy link
Contributor

@gmlewis #3761

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsReview PR is awaiting a review before merging.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Premium Requests Analytics API
4 participants