Fix: Restore full error.details handling for binary wrap-non-model-return deserializers

[joheredi]

Problem

Commit 49500efaa introduced the wrap-non-model-return feature which defaults to true for all Azure-flavored clients. The binary wrap path had two regressions:

1. Deserializer skipped error.details extraction — if (!(shouldWrap && isBinary)) completely bypassed getExceptionThrowStatement(), the only function that generates per-status-code error.details, exception headers, @clientOption headers, and restErrorCodeHeader assignment.
2. Operation function bypassed getBinaryResponse/parsedBody/parsedHeaders — an early return skipped all normal response processing.

Root Cause

The binary wrap feature introduced an early-return block in getOperationFunction that bypassed the entire normal flow (storage-compat setup, binary response helper, header deserialization, response assembly). The deserializer also took StreamableMethod directly and called getBinaryStream internally, which consumed the HttpResponse inside the deserializer scope — making it unavailable for _downloadDeserializeHeaders() in the operation function.

Fix (Approach: Split helper)

Created a new getBinaryStreamResponse static helper that only handles platform-specific stream extraction (Node: asNodeStream(), Browser: asBrowserStream()), then let the generated deserializer handle error checking using the same getExceptionThrowStatement code path as all other operations.

The key architectural change: moved getBinaryStreamResponse from inside the deserializer to the operation function level, so the HttpResponse result is in scope for all downstream consumers:

• _downloadDeserialize(result) — status check + error enrichment via getExceptionThrowStatement
• _downloadDeserializeHeaders(result) — header parsing
• addStorageCompatResponse(...) — storage-compat assembly

The deserializer parameter uses an intersection type (PathUncheckedResponse & XXXResponse) so it can access both error-handling properties and stream properties without type casts.

Changes

New files:

• static/static-helpers/serialization/get-binary-stream-response.ts — Node variant
• static/static-helpers/serialization/get-binary-stream-response-browser.mts — Browser variant

Modified files:

• src/modular/static-helpers-metadata.ts — Registered getBinaryStreamResponse helper
• src/modular/helpers/operationHelpers.ts:
  • Removed if (!(shouldWrap && isBinary)) guard that skipped the status check in the deserializer
  • Deserializer parameter uses intersection type PathUncheckedResponse & XXXResponse for binary wrap
  • Removed early-return block in operation function — binary-wrap now flows through the normal path
  • Operation function calls getBinaryStreamResponse for binary-wrap, getBinaryResponse for non-wrapped binary
  • Fixed bodyType to use wrapped response type name for StorageCompatResponseInfo generics
• test/modularUnit/scenarios/operations/wrapNonModelReturn.md — Updated binary scenario + added error enrichment scenarios
• test/modularUnit/scenarios/operations/storageCompat/storageCompatResponse.md — Added void+headers+error enrichment scenario

Generated code before vs after

Before (no error handling):

export async function _getLogsDeserialize(result: StreamableMethod): Promise<GetLogsResponse> {
  return getBinaryResponseBody(result, ["200"]);
}

After (full error handling):

export async function _getLogsDeserialize(
  result: PathUncheckedResponse & GetLogsResponse,
): Promise<GetLogsResponse> {
  const expectedStatuses = ["200"];
  if (!expectedStatuses.includes(result.status)) {
    const error = createRestError(result);
    error.details = apiErrorDeserializer(result.body);
    error.details = { ...(error.details as any), ..._getLogsDeserializeExceptionHeaders(result) };
    throw error;
  }

  return { blobBody: result.blobBody, readableStreamBody: result.readableStreamBody };
}

export async function getLogs(
  context: Client,
  options: GetLogsOptionalParams = { requestOptions: {} },
): Promise<GetLogsResponse> {
  const streamableMethod = _getLogsSend(context, options);
  const result = await getBinaryStreamResponse(streamableMethod);
  return _getLogsDeserialize(result);
}

Validation

• ✅ pnpm build — success
• ✅ npm run unit-test — 585 passing, 2 pending
• ✅ pnpm format — clean
• ✅ npm run lint — clean

[jeremymeng]

I tried 8fcaf1f build for storage-blob generation. There are compilation errors:

[browser] C:/git/jssdk/sdk/storage/storage-blob/src/Clients.ts(1354,34): error TS2345: Argument of type 'HttpNodeStreamResponse | HttpBrowserStreamResponse' is not assignable to parameter of type 'StreamableMethod'.
  Type 'HttpNodeStreamResponse' is not assignable to type 'StreamableMethod'.
    Property 'then' is missing in type 'HttpNodeStreamResponse' but required in type 'PromiseLike<PathUncheckedResponse>'.
[browser] C:/git/jssdk/sdk/storage/storage-blob/src/Clients.ts(1460,38): error TS2345: Argument of type 'HttpNodeStreamResponse' is not assignable to parameter of type 'StreamableMethod'.
  Property 'then' is missing in type 'HttpNodeStreamResponse' but required in type 'PromiseLike<PathUncheckedResponse>'.
[browser] C:/git/jssdk/sdk/storage/storage-blob/src/Clients.ts(4143,31): error TS2345: Argument of type 'HttpNodeStreamResponse | HttpBrowserStreamResponse' is not assignable to parameter of type 'StreamableMethod'.
  Type 'HttpNodeStreamResponse' is not assignable to type 'StreamableMethod'.
    Property 'then' is missing in type 'HttpNodeStreamResponse' but required in type 'PromiseLike<PathUncheckedResponse>'.
[browser] C:/git/jssdk/sdk/storage/storage-blob/src/generated/api/blob/operations.ts(3813,42): error TS2345: Argument of type 'unknown' is not assignable to parameter of type 'string'.
[browser] C:/git/jssdk/sdk/storage/storage-blob/src/generated/api/blob/operations.ts(4148,3): error TS2322: Type 'BlobDownloadResponse' is not assignable to type '{ requestId?: string | undefined; clientRequestId?: string | undefined; objectReplicationRules?: Record<string, string> | undefined; lastModified: Date; createdOn: Date; ... 39 more ...; contentCrc64?: Uint8Array<...> | undefined; } & Uint8Array<...> & StorageCompatResponseInfo<...>'.
  Type 'BlobDownloadResponse' is missing the following properties from type '{ requestId?: string | undefined; clientRequestId?: string | undefined; objectReplicationRules?: Record<string, string> | undefined; lastModified: Date; createdOn: Date; ... 39 more ...; contentCrc64?: Uint8Array<...> | undefined; }': lastModified, createdOn, contentLength, contentRange, and 12 more.
[browser] C:/git/jssdk/sdk/storage/storage-blob/src/generated/api/blockBlob/operations.ts(111,42): error TS2345: Argument of type 'unknown' is not assignable to parameter of type 'string'.
[browser] C:/git/jssdk/sdk/storage/storage-blob/src/generated/api/blockBlob/operations.ts(356,3): error TS2322: Type 'BlockBlobQueryResponse' is not assignable to type '{ lastModified: Date; contentLength: number; contentRange: string; etag: string; contentMD5: Uint8Array<ArrayBufferLike>; contentEncoding: string; ... 25 more ...; contentType: "application/octet-stream"; } & Uint8Array<...> & StorageCompatResponseInfo<...>'.
  Type 'BlockBlobQueryResponse' is missing the following properties from type '{ lastModified: Date; contentLength: number; contentRange: string; etag: string; contentMD5: Uint8Array<ArrayBufferLike>; contentEncoding: string; ... 25 more ...; contentType: "application/octet-stream"; }': lastModified, contentLength, contentRange, etag, and 9 more.

• in the unexpected response case, the result.body is not the expected string type

• the type being returned from download() doesn't match what we created for storage (StorageCompatResponseInfo which has _response, parsedHeaders, and parsedBody). We lost the parsedHeaders, parsedBody probably isn't needed in this streaming case.

[jeremymeng]

we can probably get away from casting as any for now, as storage convenience layer doesn't use the download() method

[jeremymeng]

we can probably get away from casting as any for now, as storage convenience layer doesn't use the download() method

ah not really. Previously I was relying on _downloadDeserialize() to handle the error deserialization. With this build, I cannot because it calls getBinaryStream(_streamableResult) which calls await streamableMethod.asNodeStream() which makes another request already made by my previous await streamableMethod.asNodeStream() call in convenience layer to get the response so that I can deserialize the headers. So if download() is fixed to have parsedHeaders I can probably use it directly

[jeremymeng]

So currently _downloadDeserialize() sends the request, gets the response, returns the streaming body shape { blobBody, readableStreamBody,} but it doesn't return the http response, so I have nothing to feed _downloadDeserializeHeaders()

[jeremymeng]

I pushed a branch to show the issue and my manual fix. Not sure if it is easy to update the code gen to have similar fix, when the operation is returning stream body AND storage compat option is enabled.

• branch: https://github.com/Azure/azure-sdk-for-js/tree/storage/codegen-issue-and-manual-fix
• changes from codegen: Azure/azure-sdk-for-js@604f94b
• manual fix which now allows us to use the generated method without any workaround: Azure/azure-sdk-for-js@80194bb

my manual fix includes

• move await getBinaryStream(streamableMethod) into _downloadDeserialize so that its result can be passed to _downloadDeserialize and _downloadDeserializeHeaders
• update the parameter of _downloadDeserialize so that it takes the return value from getBinaryStream()
• update return types of streaming methods to not have the incorrect Uint8Array return type