feat(csharp): expose metadata on paginated responses#14762
Conversation
There was a problem hiding this comment.
Claude Code Review
This repository is configured for manual code reviews. Comment @claude review to trigger a review and subscribe this PR to future pushes, or @claude review once for a one-time review.
Tip: disable this comment in your organization's Code Review settings.
🌱 Seed Test SelectorSelect languages to run seed tests for:
How to use: Click the ⋯ menu above → "Edit" → check the boxes you want → click "Update comment". Tests will run automatically and snapshots will be committed to this PR. |
fc6f1f1 to
6bfaf63
Compare
SDK Generation Benchmark ResultsComparing PR branch against latest nightly baseline on Full benchmark table (click to expand)
main (generator): generator-only time via --skip-scripts (includes Docker image build, container startup, IR parsing, and code generation — this is the same Docker-based flow customers use via |
SDK Generation Benchmark ResultsComparing PR branch against latest nightly baseline on Full benchmark table (click to expand)
main (generator): generator-only time via --skip-scripts (includes Docker image build, container startup, IR parsing, and code generation — this is the same Docker-based flow customers use via |
23073cf to
ca604d8
Compare
ca604d8 to
c599d03
Compare
SDK Generation Benchmark ResultsComparing PR branch against latest nightly baseline on Full benchmark table (click to expand)
main (generator): generator-only time via --skip-scripts (includes Docker image build, container startup, IR parsing, and code generation — this is the same Docker-based flow customers use via |
Description
Equivalent of #10629 in C#.
Added three new properties to
Page<TItem>:Response(object?), the full deserialized API response objectHttpStatusCode), the HTTP status codeResponseHeaders?), the HTTP response headersPager now explicitly calls
.WithRawResponse()soPagecan haveResponse. There was a somewhat suboptimal design decision made here to avoid a breaking change; namely, I'd rather have expanded the interface ofPagertoPager<TResponse, TItem>so users wouldn't have to castResponseto the correct type to use it, but that would break any code that implemented the interface. I'd theoretically be alright with this since getting the raw response here is a relatively fringe use case compared to the status code or headers, but it's still a compromise.Code example:
Testing
Regeneration of all pagination fixtures.