You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Hide continuation-token parameters on nextLink-paged C# operations - #12469
nextLink-paged operations can expose a bare continuation-token request parameter even though callers resume paging with a nextLink URL. These incompatible token formats invite incorrect requests.
Metadata: Preserve the request-token marker even when the response has no continuation token.
Public API: Omit marked tokens from sync/async convenience and protocol signatures; pass default internally. Leave token-only paging unchanged.
Compatibility: Retain published token-bearing signatures as [EditorBrowsable(Never)] overloads that still send the token, preserve trailing optional arguments, and coexist with optional-parameter compatibility overloads.
Azure Pipelines:
Successfully started running 1 pipeline(s).
1 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.
CopilotAI
changed the title
[WIP] Fix exposure of @continuationToken request parameter
Hide continuation-token parameters on nextLink-paged C# operations
Nov 2, 2026
Add opt-in SupportsPageResumption to the response APIs and preserve unbranded paging signatures by default.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Replace the paging metadata reference with IsContinuationToken and preserve grouped parameter forwarding and unbranded paging behavior.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
Critical overload-matching and paging-argument errors can drop published tokenless methods and generate invalid constructor calls, breaking compilation and backward compatibility.
This PR adds support for hiding raw continuation-token parameters on nextLink-paged C# operations when the response provider supports page resumption, addressing #12468.
Changes:
Preserve request continuation-token metadata independently of response-token metadata.
Omit marked tokens from eligible public signatures and pass default internally, leaving token-only paging unchanged.
Add hidden compatibility overloads, regression tests, and updated code-model fixtures.
Paths below are relative to packages/http-client-csharp/.
Merge current main, retaining continuation-token tests and honoring the lifecycle visibility revert. Warn and retain raw-token APIs on signature collisions, preserve published tokenless methods during regeneration, and fix mixed grouped parameter forwarding.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
Page-resumption overload generation can leave public partial methods without implementations, causing CS8795, and make previously valid calls ambiguous through overlapping optional arguments.
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
Critical compatibility regressions can produce duplicate partial implementations, make previously valid calls ambiguous, and omit published continuation-token overloads.
If the last contract names the token resumeToken but the current input names it token and there is no current partial declaration, this name check returns -1, so AddContinuationTokenOverloads never retains the published overload (for example, using the existing CustomProtocolLast fixture without CustomProtocol). Match the baseline parameter structurally/positionally and restore its published name, rather than requiring it to match the current token name.
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
Critical overload-collision gaps can drop required partial implementations and introduce ambiguous calls, causing compilation failures for customizations and published contracts.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
Human assessment is needed because subtle named-argument and optional-parameter interactions can make previously valid paging calls fail to compile or become ambiguous.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
nextLink-paged operations can expose a bare continuation-token request parameter even though callers resume paging with a nextLink URL. These incompatible token formats invite incorrect requests.
defaultinternally. Leave token-only paging unchanged.[EditorBrowsable(Never)]overloads that still send the token, preserve trailing optional arguments, and coexist with optional-parameter compatibility overloads.Representative convenience signature: