Adding File to Vector Results in Indexing Failure - Internal Error Occurred

Hello Alisha,

Thanks for reaching out to Microsoft Q&A,

From what you’ve described, your flow looks correct end-to-end, so the 500 “Internal Error occurred” during vector_store_files.create_and_poll is very likely happening during the ingestion/indexing phase, not during file upload or vector store creation.

This is a known rough edge right now with the Agents + vector store pipeline in Azure AI Foundry, where the service can return a generic 500 instead of a more descriptive error. Based on similar cases, here are the areas I’d suggest checking:

1. RBAC and service access

Even if the container app can access resources, the ingestion pipeline internally touches multiple services.

Please make sure the identity you’re using has:

• Contributor (or higher) on the Foundry/Agent resource
• Contributor on Azure AI Search
• Storage Blob Data Contributor on the storage account

One thing to watch out for here is propagation delay role assignments that were just added can still cause failures for a few minutes.

2. File format and encoding

TXT files are supported, but the ingestion pipeline is sensitive to formatting.

Things that can cause failures:

• Non UTF-8 encoding
• Hidden/control characters
• Very large continuous blocks of text without breaks

I’d recommend:

• Re-saving the file as UTF-8
• Cleaning up any unusual characters
• Splitting large paragraphs into smaller chunks

3. File size and structure

While the documented limits are quite high (hundreds of MB / millions of tokens), in practice the ingestion step can fail earlier depending on how the content is structured.

If your file is large:

• Try splitting it into smaller files
• Keep individual files ideally under ~5–10 MB for testing

4. Vector store readiness / timing

Even though you’re using the create_and_poll helpers, there are cases where the backend isn’t fully ready immediately after creation.

Before attaching the file, it’s worth:

• Verifying the vector store status is actually “completed”
• Adding a small delay (2–3 seconds) before calling vector_store_files.create_and_poll

This helps avoid race conditions in the ingestion pipeline.

5. File ID consistency

Just check that the file_id you’re passing is exactly the one returned from the upload call (file.id). A mismatch here can sometimes surface as a generic internal error rather than a validation error.

6. Region or dependency alignment

Vector ingestion relies on underlying embedding capabilities. If there’s any mismatch between:

• Foundry project region
• Search resource
• Model availability

you can hit failures at indexing time.

To narrow this down this:

• Upload a very small TXT file (1–2 KB, simple content like “hello world”)
• Create a new vector store
• Attach that file

If this works, the issue is almost certainly with the original file (size, structure, or encoding). If it still fails, then we’re likely looking at RBAC, region, or a backend issue.

Integrated Vectorization Troubleshooting Guide https://dotnet.territoriali.olinfo.it/azure/search/search-indexer-troubleshooting

Vector stores for file search (troubleshooting section) https://dotnet.territoriali.olinfo.it/en-us/azure/foundry/agents/concepts/vector-stores?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#troubleshooting

Foundry Agent Service limits, quotas, and regional support https://dotnet.territoriali.olinfo.it/en-us/azure/foundry/agents/concepts/limits-quotas-regions?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#limit-error-reference

File search tool for agents (REST) – troubleshooting table https://dotnet.territoriali.olinfo.it/azure/foundry/agents/how-to/tools/file-search?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#troubleshooting

500 status code deep-dive (Prompt Flow) https://supportability.visualstudio.com/AzureML/_wiki/wikis/AzureML/1553064/AMLService(Vienna)/TSGs/Prompt Flow/500 status code

I Hope this helps. Do let me know if you have any further queries.

Thank you!

Thank you for the steps.

Please see my updates below:

1. RBAC: I assigned Contributor role for Container App Identity to Foundry and Search. No change.
2. File format and encoding: The text files are created by code and created with UTF-8. Note: I even split the file further, it still fails.
   File ID consistency: File ID matches.
3. Region: Both Foundry, search, storage and Container app where the code runs is in eastus2.

Please note, the Foundry project was created with Capability hosts defined with user managed Seacrh, storage and cosmos db. However, when the Indexes are created for the files by the above code, it still shows 'ManagedSearch'.

As per the documentation, no change is needed in the code for the File Search Tool to use the user managed resources and not the Azure managed resources.

Thank you for the steps.

Please see my updates below:

1. RBAC: I assigned Contributor role for Container App Identity to Foundry and Search. No change.
2. File format and encoding: The text files are created by code and created with UTF-8. Note: I even split the file further, it still fails. File ID consistency: File ID matches.
3. Region: Both Foundry, search, storage and Container app where the code runs is in eastus2.

Please note, the Foundry project was created with Capability hosts defined with user managed Seacrh, storage and cosmos db. However, when the Indexes are created for the files by the above code, it still shows 'ManagedSearch'.

As per the documentation, no change is needed in the code for the File Search Tool to use the user managed resources and not the Azure managed resources.

Hi Alisha,

Thank you for the detailed update

observation from your note

“Indexes still show ManagedAzureSearch even though the project was created with user-managed Search, Storage, and Cosmos DB.”

This is an signal.

In the current Foundry Agent Service behavior, vector stores created via the Agents SDK are still backed by Foundry-managed infrastructure, even when your project is configured with user-managed resources.

So what you’re seeing Type = ManagedAzureSearch is expected behavior today, not a misconfiguration in your code.

What this implies

Because the ingestion pipeline is using managed backend resources, the failure you’re hitting:

“Indexing failed – Internal error occurred”

is happening inside the managed ingestion/vectorization pipeline, not in your:

• Container App
• RBAC setup
• User-managed Search service

You’ve already confirmed:

• RBAC is correctly assigned
• UTF-8 encoding and file splitting done
• File ID consistency
• Same region (eastus2)
• Reproducible behavior

At this point, this strongly points to one of the following:

1. Backend ingestion issue

A failure in the managed vector ingestion pipeline, which can surface as a generic 500.

2. Hidden content parsing edge case

Even valid UTF-8 files can fail if:

• Unexpected control characters exist
• File has unusual structure (e.g., long unbroken lines, encoding artifacts)
• Parser fails silently

The fact that splitting didn’t help reduces likelihood, but doesn’t fully eliminate it.

3. Service-side limitation / bug

• Managed resources are being used regardless of your configuration
• Error is generic (500)
• Happens during indexing phase only

This aligns closely with a known limitation / product gap in the current Agents and vector store ingestion flow

Recommended next steps

1. Try a minimal controlled test

Create a brand new file with:

Hello world.

Then Upload - create vector store → attach file

If this fails → confirms service/backend issue, If this works → confirms content-specific ingestion issue

2. Inspect file content at byte level

Even if generated via code Check for:

• • BOM markers
  • Null bytes (\x00)
  • Non-printable characters

3. Add a short delay before ingestion

Even with create_and_poll, try:

await asyncio.sleep(3)

before calling:

vector_store_files.create_and_poll(...)

Thank you!