[search-documents] getDocument throws TypeError when error response body is undefined

[adamalfredsson]

• Package Name: @azure/search-documents
• Package Version: 13.0.0
• Operating system: macOS (darwin 25.5.0)
• nodejs
  • version: 22.14.0
• browser
  • name/version:
• typescript
  • version: 5.9.3
• Is the bug related to documentation in
  • README.md
  • source code documentation
  • SDK API docs on https://learn.microsoft.com

Describe the bug

When SearchClient.getDocument() is called for a document key that does not exist, Azure Search returns a non-200 response (404) with an empty/undefined response body. The SDK then crashes while deserializing the error response instead of throwing a proper RestError.

errorResponseDeserializer in dist/esm/models/azure/search/documents/models.js accesses item["error"] without checking that item is defined. _getDocumentDeserialize passes result.body directly:

error.details = errorResponseDeserializer(result.body);

When result.body is undefined, this throws:

TypeError: Cannot read properties of undefined (reading 'error')

Callers expecting a RestError with statusCode: 404 cannot handle the failure as a normal not-found case.

To Reproduce

Steps to reproduce the behavior:

1. Create a SearchClient for an existing index (API version defaults to 2026-04-01).
2. Call getDocument() with a key that does not exist in the index.
3. Observe that the SDK throws TypeError: Cannot read properties of undefined (reading 'error') instead of a RestError with status code 404.

Minimal example:

import { AzureKeyCredential, SearchClient } from "@azure/search-documents";

const client = new SearchClient(
  process.env.AZURE_SEARCH_ENDPOINT!,
  "my-index",
  new AzureKeyCredential(process.env.AZURE_SEARCH_KEY!)
);

// Use a UUID/document key that does not exist in the index
await client.getDocument("4e7ea399-7f14-4ce5-8fa1-bbc7020cc25f");

Expected behavior

The SDK should throw a RestError (or equivalent Azure client error) with statusCode: 404 when the document is not found, even if the error response body is empty or missing. errorResponseDeserializer should guard against undefined input.

Screenshots

N/A

Additional context

• Stack trace points to:
  • errorResponseDeserializer — dist/esm/models/azure/search/documents/models.js:7
  • _getDocumentDeserialize — dist/esm/search/api/operations.js:261
  • getDocument — dist/esm/search/api/operations.js:269
• The same pattern (errorResponseDeserializer(result.body)) appears in many other operation deserializers, so they may be affected by empty error bodies too.
• Workaround: guard in errorResponseDeserializer:

export function errorResponseDeserializer(item) {
    if (!item) {
        return { error: undefined };
    }
    return {
        error: !item["error"] ? item["error"] : errorDetailDeserializer(item["error"]),
    };
}

• Reproduced in a Next.js server environment using ESM (import), but the issue is in the SDK's compiled output, not app-specific bundling.

[github-actions]

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

//cc: @srbalakr @efrainretana

[github-actions]

🎯 Agentic Issue Triage

Summary: SearchClient.getDocument() crashes with a TypeError when a document is not found (404), because errorResponseDeserializer dereferences result.body without guarding against undefined. Callers cannot catch this as a normal not-found case.

📋 Issue Details

Package: @azure/search-documents v13.0.0
Affected API: SearchClient.getDocument() → _getDocumentDeserialize → errorResponseDeserializer
Scenarios:

• Calling getDocument() with a key that does not exist in the index triggers a 404 response with an empty/undefined body
• The deserializer at dist/esm/models/azure/search/documents/models.js:7 accesses item["error"] without checking whether item is defined, causing a TypeError
• The same errorResponseDeserializer(result.body) pattern appears in many other operation deserializers, so the impact may be broader

Root ask: errorResponseDeserializer should guard against undefined input and surface a proper RestError with statusCode: 404 rather than a TypeError.

🔎 Debugging / Reproduction Notes

The crash path is:

1. getDocument() calls the underlying REST operation
2. Azure Search returns HTTP 404 with an empty response body
3. _getDocumentDeserialize (operations.js:261) passes result.body (which is undefined) directly to errorResponseDeserializer
4. errorResponseDeserializer accesses item["error"] without a null-guard, throwing TypeError: Cannot read properties of undefined (reading 'error')

The author provides a working workaround: add an early return in errorResponseDeserializer when item is falsy.

Suggested investigation steps:

1. Confirm that result.body can be undefined for 404 responses from the Azure Search REST API (empty body) — verify with a live repro or recorded test
2. Audit all callers of errorResponseDeserializer(result.body) across operations.js (the author notes many similar call sites) to assess the full blast radius
3. Add a null-guard in errorResponseDeserializer (similar to the workaround proposed by the author) and verify that RestError with statusCode: 404 is surfaced to callers
4. Add or update a test that calls getDocument() with a nonexistent key and asserts a RestError with statusCode: 404

🏷️ Label Confidence

• Category: Client — @azure/search-documents is a data-plane client library under sdk/search/search-documents, not a management SDK
• Service: Search — package maps to the Azure AI Search service; confirmed by multiple quality reference issues (Connect to Azure Search service using Managed Identity via @azure/identity #35393, resourceUrl should be resourceUri? #31458) using the same Client + Search label pair
• Confidence: High — package is explicitly named in the issue title and body, category and service are unambiguous, and the label pattern is confirmed by quality reference issues

👥 Owner Routing

• Matched CODEOWNERS entry: # ServiceLabel: %Search (line 285) — requires only the "Search" service label, which is present
• AzureSdkOwners: @srbalakr, @efrainretana (line 284: # AzureSdkOwners: @srbalakr @efrainretana``)
• ServiceOwners: none listed for this entry
• Routing action: Assigned @srbalakr (random pick from two AzureSdkOwners); added needs-team-attention label; @mentioned both AzureSdkOwners in routing comment
• Scan notes: During bottom-to-top scan, # ServiceLabel: %Search %Service Attention (line 1452) was encountered first but did not match because the issue does not carry the "Service Attention" label; scan continued upward to # ServiceLabel: %Search (line 285), which matched on "Search" alone

Generated by Agentic Triage for issue #38842 · ● 4.2M · ◷

[maorleger]

@adamalfredsson thanks so much for creating this issue and adding the details!

@srbalakr I believe this has been recently fixed in the code generator (Azure/autorest.typescript#3948). I think we have two options:

1. Manually fix this in search-documents and release 13.0.1 off of the latest GA branch / tag
2. Regenerate search-documents using the GA typespec off of the latest GA branch / tag but using the latest emitter version

Given the branching drift over time I almost think (1) is easier to apply but happy to chat about options

The fix should look something like https://github.com/Azure/autorest.typescript/pull/3948/changes#diff-6de49c8487ededc8fd24713af77d69b5cdf4b0082659647ea2868f4aac661d60R197-R198 and probably needs to be applied to every deserializer. It's possible that not every deserializer actually needs this guard but it's not harmful to do (even if unnecessarily) and is probably easier for copilot to fix that way