[core] Unsupported request bodies receive a retryable error code #40387

Activity

1. aanubhav-msft

   assigned

   Jeremy Meng (jeremymeng)

   on Oct 19, 2026
2. github-actions

   added

   ClientThis issue points to a problem in the data-plane of the library.This issue points to a problem in the data-plane of the library.

   Azure.Core

   on Oct 19, 2026
3. github-actions commented on Oct 19, 2026

   

   github-actionsBot

   on Oct 19, 2026 – with GitHub Actions

   Contributor

   More actions

   Thank you for your feedback. Tagging and routing to the team member(s) best able to assist.

   Generated by Agentic Triage for #40387 · copilot · auto · 42.9 AIC · ⌖ 8.6 AIC · ⊞ 15.9K · ◷
4. github-actions

   added the

   Bug

   issue type on Oct 19, 2026
5. github-actions commented on Oct 19, 2026

   

   github-actionsBot

   on Oct 19, 2026 – with GitHub Actions

   Contributor

   More actions

   🎯 Agentic Issue Triage

   Summary: Unsupported request body types (e.g., a Node Blob) now cause the Node transport in @typespec/ts-http-runtime to fail with a retryable REQUEST_SEND_ERROR, causing Storage's default retry policy to retry for ~16 seconds before failing, instead of failing fast with a non-retryable error.

   📋 Issue Details

   Package: @typespec/ts-http-runtime (unreleased changes in PR #40258), @azure/storage-blob
   Affected API: Node HTTP transport body-handling / "Unrecognized body type" error path
   Scenarios:

   • Sending a Node Blob or other unsupported request body type via the new Node transport from PR [core] Support opt-in Expect: 100-continue in Node HTTP/1 transport #40258
   • Using Storage's default retry policy on top of that transport

   Root ask: Unsupported body types should surface a non-retryable error immediately, rather than a retryable REQUEST_SEND_ERROR that gets retried ~16 seconds before ultimately failing.

   🔎 Debugging / Reproduction Notes

   This was observed while testing PR #40258, which changes how the Node transport validates/handles request bodies. The error code currently assigned to "Unrecognized body type" appears to match other transient/retryable network errors, causing Storage's default retry policy to treat it as retryable.

   Suggested investigation steps:

   1. Locate where "Unrecognized body type" is thrown in the Node transport (likely in sdk/core/core-rest-pipeline or the ts-http-runtime Node HTTP sender introduced in [core] Support opt-in Expect: 100-continue in Node HTTP/1 transport #40258) and inspect the error code/classification assigned.
   2. Compare against the previously released core behavior to confirm it failed immediately (non-retryable) for the same scenario.
   3. Update the error classification so "Unrecognized body type" is explicitly marked non-retryable (e.g., a distinct error code or a flag checked by the retry policy), then verify Storage's retry policy no longer retries it.

   🏷️ Label Confidence

   • Category: Client — The issue concerns client-side transport and retry behavior in sdk/core, not a management-plane (@azure/arm-*) package.
   • Service: Azure.Core — The issue is rooted in @typespec/ts-http-runtime / core transport behavior (sdk/core), referenced alongside @azure/storage-blob only as the consumer exhibiting the symptom.
   • Confidence: High — The issue explicitly references sdk/core packages (@typespec/ts-http-runtime) and PR [core] Support opt-in Expect: 100-continue in Node HTTP/1 transport #40258 under sdk/core, with no ambiguity about the affected area.

   👥 Owner Routing

   • Matched CODEOWNERS entry: # ServiceLabel: %Azure.Core (line 77) — bottom-to-top scan found no multi-label entries combining "Azure.Core" with other predicted labels; this single-label entry matched first among Azure.Core entries.
   • AzureSdkOwners: @Azure/azure-sdk-for-js-core (team, not an individual assignable user)
   • ServiceOwners: none listed
   • Routing action: No individual assign_to_user call made since the listed owner is a team (not assignable as a single GitHub user); issue is already assigned to jeremymeng. Author is a repo MEMBER, so customer-reported/needs-team-attention labels were not applied per the author decision flow.
   • Scan notes: Lines 73 and 79 are # PRLabel: %Azure.Core entries (for PR-time labeling, not ServiceLabel issue routing) and were skipped; no other Azure.Core or multi-label combinations exist further down the file.

   Generated by Agentic Triage for #40387 · copilot · auto · 42.9 AIC · ⌖ 8.6 AIC · ⊞ 15.9K · ◷