Document Intelligence InternalServer Error

Question

Document Intelligence InternalServer Error

Cristian Razvan 0

Hello!

When I am using document inteligence with a multipage document with 360 pages ( but the documentation is saying that the model can receive up to 2000 pages...) the AnalyzeDocumentAsync function error out with the InternalServerError like so:

at Azure.Core.OperationInternal1.GetResponseFromState(OperationState1 state)

at Azure.Core.OperationInternal`1.<UpdateStatusAsync>d__20.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at Azure.Core.OperationInternalBase.<UpdateStatusAsync>d__13.MoveNext()

......

An unexpected error occurred.

Status: 200 (OK)

ErrorCode: InternalServerError

Additional Information:

AdditionInformation: InternalServerError: An unexpected error occurred.

Details:

InternalServerError: An unexpected error occurred.

Raw:

{"code":"InternalServerError","message":"An unexpected error occurred.","details":[{"code":"InternalServerError","message":"An unexpected error occurred."}]}

Content:

{"status":"failed","createdDateTime":"2026-06-30T06:07:45Z","lastUpdatedDateTime":"2026-06-30T06:07:45Z","error":{"code":"InternalServerError","message":"An unexpected error occurred.","details":[{"code":"InternalServerError","message":"An unexpected error occurred."}]}}

Headers:

x-envoy-upstream-service-time: 88

apim-request-id: a58c6bf9-bb37-466c-bde0-17489d08ff6b

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

x-content-type-options: nosniff

x-ms-region: REDACTED

Content-Length: 271

Content-Type: application/json; charset=utf-8

Date: Tue, 30 Jun 2026 08:07:47 GMT

It errors out after 2 hours of waiting for the result....

Also 2 hours to parse 360 pages it's outrageously a long time but to even error out after that ....

When i am using the rest api to get the result using the operation id ( 136f0a49-bbc3-4129-b7c6-6feef359fa2a ) i got:

{
    "error": {
        "code": "NotFound",
        "message": "Resource not found.",
        "innererror": {
            "code": "OperationNotFound",
            "message": "The requested operation was not found. The identifier may be invalid or the operation may have expired."
        }
    }
}

It doesn't even found the operation ...

What do we do in this situation , also the pages will be billed because the service didn't return any result but an error?

We should batch the analyze for 300 pages? Seems allot of code changes for not very big documents...

Thanks!

Aditya N 2,990 Reputation points Microsoft External Staff Moderator

2026-06-30T09:33:56.75+00:00

Hello @Cristian Razvan

Thank you for reaching out Microsoft Q&A. We're looking into your query, we'll get back to you shortly.
SRILAKSHMI C 19,550 Reputation points Microsoft External Staff Moderator

2026-06-30T13:08:24.9566667+00:00
Hello @Cristian Razvan

Thank you for providing the detailed error information, including the exception stack trace, Operation ID, APIM Request ID, and the behavior you observed. I understand how frustrating it is for a document analysis request to run for nearly two hours and ultimately fail with an InternalServerError, especially when the document is well within the documented service limits.

Based on the information you've shared and the available documentation, here's what we can infer.

Your request is initially accepted successfully (HTTP 200 OK), which indicates that the Document Intelligence service accepted the analysis request. However, during processing, the operation transitions to a failed state with:

{ "code": "InternalServerError", "message": "An unexpected error occurred." }

An InternalServerError generally indicates an unexpected service-side failure during processing rather than an issue with the client request itself. When available, additional information may be provided in the error.details or innererror fields, although in your case the service only returned the generic error.

Regarding the subsequent REST call returning:

{ "error": { "code": "NotFound", "innererror": { "code": "OperationNotFound" } } }

this is also consistent with the documented behavior. An OperationNotFound response can occur when:

the operation identifier is invalid,

the operation has expired, or

the failed long-running operation is no longer available for retrieval.

Therefore, it is expected that after the operation fails, the same operation ID may no longer return status information.

About the document size

Although your document contains 360 pages, which is well below the documented maximum supported page limit (up to 2,000 pages for supported models), the maximum supported page count does not guarantee that every large document will complete successfully.

Processing time and success can also depend on factors such as:

document complexity

image quality and resolution

scanned versus digitally generated PDFs

tables and complex layouts

embedded images or objects

overall service load

A document within the supported limits can still encounter transient processing failures.

Would splitting the document help?

Based on the troubleshooting guidance in the documentation, yes.

Although batching isn't a documented requirement, for large or complex documents it is considered a best practice to split them into smaller batches (for example, 100–200 pages per request) before analysis.

Given the symptoms you've observed:

approximately two-hour processing time,

eventual InternalServerError, and

inability to retrieve the completed operation,

processing the document in smaller batches can improve resiliency, reduce retry scope, and minimize the impact of transient service-side failures.

If your request uses a Blob Storage URL (SAS URI) rather than uploading the document directly, it's also worth verifying the storage configuration.

The documentation recommends checking:

the SAS token is still valid and has not expired,

the storage account firewall or networking configuration allows access,

if using Managed Identity, the Document Intelligence resource has the appropriate Storage Blob Data Reader permissions.

While storage-related issues often return client-side errors such as 400 Bad Request, they are still worth validating if the service is retrieving the document from storage.

Since this is an unexpected server-side failure, we also recommend checking:

Azure Service Health

Azure Resource Health

Azure Monitor metrics

to determine whether there were any service incidents or regional capacity issues during the processing timeframe.

About billing

You also asked whether the pages will be billed even though the operation failed.

At this time, the available documentation does not explicitly specify whether pages processed during a failed InternalServerError operation are billable. Therefore, we cannot conclusively confirm the billing behavior based solely on the public documentation.

If you'd like Microsoft to verify whether billing occurred for this specific request, we recommend opening a support request so the backend team can review the processing logs and billing records associated with the operation.

Please refer this

Error guide v4.0, v3.1, v3.0 (Document Intelligence unified error handling; meaning of InternalServerError) https://learn.microsoft.com/azure/ai-services/document-intelligence/how-to-guides/resolve-errors?view=doc-intel-4.0.0

Please do let me know if you have further queries.

Thank you!
SRILAKSHMI C 19,550 Reputation points Microsoft External Staff Moderator

2026-07-01T11:35:24.3033333+00:00

Hi @Cristian Razvan

Did you get any chance to review the above response. Do let me know if you have any further queries.

Thank you!
SRILAKSHMI C 19,550 Reputation points Microsoft External Staff Moderator

2026-07-02T02:01:34.4333333+00:00

Hi @Cristian Razvan

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Thank you!
Cristian Razvan 0 Reputation points

2026-07-02T06:12:53.9566667+00:00
Hello!

Yea ..so I implemented batching .
I am splitting's the documents in batches of 50 pages and make in parallel n requests for n batches.
This modification dropped the processing time for that document (365 scanned pages) from over 2 hours to about 6 to 7 minutes but introduced allot of code changes and posibile future bugs because u have to join the analyzed result from n batches into one.

I do have some other problems:

The vision model is inconsistent , a request with one page and a request with the same page included in a document with 3 pages for example doesn't return the same result for that page .

What i mean is : pages that worked very well when we where using the request as one page-one document now (some of them) are broken when we send documents with multiple pages ( the batching from above)

Also i tried , trough the sdk , a document with 150 pages and it worked but parsed wrong some pages and so i wanted to try it in the document intelligence studio to see (visually) where it got it wrong and to also train the model but the studio couldn't parse the document and i got:

Some suggestions:

Allow batching trough sdk without the need to store the files in an azure blob, just give the file and the batch size and the server should split that document in batches but assign just one operation id (just like the batching that is now implemented but that is for another solution , when u have multiple different documents not one document that u want to split in batches

Maybe make the functionality from 1. automated? If the azure receiver see's that the document is above some nr of pages split it automatically and join the results

Before i noticed that the big files where failing there where many requests made that resulted in a InternalServerError, it should be implemented automatically that if that is the case the document shouldn't be billed

Now I know that some of the suggestions are out of your scope but maybe someone will see them here and take note.

Your suggestion of batching the requests was the intuition that I had and you confirmed it so thank you for that!

Have a nice day!