Skip to content

Promote 14 pagination and error-handling scenarios from Backlog to Core - #5086

Open
iscai-msft wants to merge 1 commit into
mainfrom
promote-pagination-error-scenarios-to-core
Open

Promote 14 pagination and error-handling scenarios from Backlog to Core#5086
iscai-msft wants to merge 1 commit into
mainfrom
promote-pagination-error-scenarios-to-core

Conversation

@iscai-msft

Copy link
Copy Markdown
Contributor

Summary

Moves 14 scenarios from Backlog to Core tier in the Can I Use dashboard.

Pagination (12 scenarios)

These patterns are used by every Azure list operation:

  • ContinuationToken (6): All combinations of header/query request with body/header/nested response
  • Link-based (3): link, linkString, nestedLink
  • PageSize (2): listWithPageSize, listWithoutContinuation
  • XML Pagination (2): listWithContinuation, listWithNextLink

Error Handling (2 scenarios)

Every service returns errors; these test distinct wire behavior:

  • Response_StatusCodeRange_errorResponseStatusCodeInRange
  • Response_StatusCodeRange_errorResponseStatusCode404

Rationale

Using the rubric:

  1. Service Prevalence: All Azure list operations use pagination; all services return error status codes
  2. Wire Correctness: Each tests a distinct request/response pattern not covered by other Core scenarios
  3. SDK Usability: Users would file bugs if pagination or error handling didn't work

Current adoption (unbranded emitters)

  • 4 of these are already passing in all 4 languages (Python/C#/JS/Java)
  • 8 more are passing in 3/4 (only JS missing — newest emitter)
  • 2 are passing in Python/C#/Java

These scenarios test fundamental patterns used by shipped Azure services:

Pagination (12 scenarios):
- ContinuationToken (6): header/query request × body/header/nested response
- Link-based (3): link, linkString, nestedLink
- PageSize (2): listWithPageSize, listWithoutContinuation
- XML Pagination (2): listWithContinuation, listWithNextLink

Error handling (2 scenarios):
- Response_StatusCodeRange_errorResponseStatusCodeInRange
- Response_StatusCodeRange_errorResponseStatusCode404

Rationale: These patterns appear in real Azure services (every list operation
uses pagination, every service returns errors with status code ranges). They
test distinct wire-format behavior not covered by other Core scenarios, and
users would file bugs if these didn't work in generated SDKs.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 421f24e7-8a8e-4dad-b066-2c4e974abd68
@github-actions

Copy link
Copy Markdown
Contributor

No changes needing a change description found.

@azure-sdk-automation

Copy link
Copy Markdown
Contributor

You can try these changes here

🛝 Playground 🌐 Website

"Payload_Pageable_ServerDrivenPagination_ContinuationToken_requestHeaderResponseHeader",
"Payload_Pageable_ServerDrivenPagination_ContinuationToken_requestQueryNestedResponseBody",
"Payload_Pageable_ServerDrivenPagination_ContinuationToken_requestQueryResponseBody",
"Payload_Pageable_ServerDrivenPagination_ContinuationToken_requestQueryResponseHeader",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

any azure service doing this? continuationToken on header?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Same concern with weidong, are these promoted tests used by read service?

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

Labels

meta:website TypeSpec.io updates

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants