`azure-ai-agentserver-responses` `storage_error` masks the real underlying error (content_filter, timeout, etc.) in Foundry-hosted agent responses

[mhmtkcm]

• Package Name: azure-ai-projects / agent-framework-foundry-hosting / azure-ai-agentserver-responses
• Package Version: 2.1.0 / 1.0.0a260507 / 1.0.0b5
• Python Version: 3.13.13

---

Describe the bug

When sending requests to a Foundry-hosted agent and retrieving the agent response via polling, the polling process intermittently fails with a misleading storage_error.

The error message returned is:

Error code: storage_error
Error message: An internal error occurred while storing the response. Subsequent retrieval is not guaranteed. Please retry the request.

After further investigation, this error appears not to be an actual storage issue on the backend. Instead, it seems to originate from a content filter triggered on the OpenAI side, but the error is not being propagated to the user correctly.

Expected OpenAI behavior:
When the OpenAI content filter is triggered, the response object should normally contain:

• "status": "incomplete"
• "incomplete_details": { "reason": "content_filter" }

Observed behavior in Foundry-hosted agents:

• "status" is returned as "failed" instead of "incomplete".
• "error_code" is returned as "storage_error", which is not a valid value in OpenAI's defined ResponseError codes.
• The actual root cause (content_filter) is completely hidden from the user, making it impossible to handle the situation properly (e.g., by adjusting the prompt or informing the end user that the content was filtered).

Because of this incorrect mapping, what is actually a deterministic content-filter rejection appears to the user as a random/intermittent storage failure, since the same input may pass or trigger the content filter depending on the model's non-deterministic output.

I also suspect that this same generic storage_error may be masking other underlying error types as well (e.g., timeouts, upstream model errors, or other transient failures). Since all of these seem to be collapsed into a single storage_error code, it is currently impossible to distinguish between fundamentally different failure modes from the client side.

Screenshot

To Reproduce

1. Send a request to a Foundry-hosted agent using azure-ai-projects (OpenAI client / responses API).

2. Use a prompt whose response is likely to trigger the OpenAI content filter.

3. Retrieve the agent response via the polling mechanism. (polling may be optional)

4. Observe that the request fails with:

   • "status": "failed"
   • "error_code": "storage_error"

   instead of the expected:

   • "status": "incomplete"
   • "incomplete_details": { "reason": "content_filter" }

Expected behavior

• When the OpenAI content filter is triggered, the response should be returned with "status": "incomplete" and "incomplete_details.reason": "content_filter", in line with the OpenAI Responses API contract.
• The error_code field should only contain values defined by OpenAI's ResponseError schema; custom/undefined values such as storage_error should not be used to mask content-filter rejections.
• Other underlying failures (timeouts, upstream errors, etc.) should likewise be surfaced with their own distinct, accurate error codes rather than being collapsed into a generic storage_error.
• The user should be able to distinguish a genuine backend storage failure from a content-policy rejection, so that the issue can be handled appropriately on the client side.

[github-actions]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @bobogogo1990 @dargilco @glharper @howieleung @kingernupur @nick863 @trangevi @trrwilson.