Intermittent 400 "Blocklist with name X not found" for a blocklist that exists

Question

Intermittent 400 "Blocklist with name X not found" for a blocklist that exists

Stefan Fleck 20

AnalyzeText intermittently returns HTTP 400 InvalidRequestBody — "Blocklist with name REDACTED not found, index = 0" — for a blocklist that exists and was not modified. The identical request succeeds seconds before and after the failure, from the same client instance against the same endpoint.

Questions

Is blocklist metadata eventually consistent across the instances behind one endpoint, so a blocklist that has existed for weeks can briefly vanish?
Is 400 the intended status here? It tells clients the request is malformed and must not be retried, so the SDK's retry policy correctly refuses to retry a condition that resolves itself within seconds.

What we see

Azure.AI.ContentSafety 1.0.0 (.NET), one singleton ContentSafetyClient, one endpoint, one key. Every call is built identically — the blocklist name is a static config value, no code path ever omits or changes it.

On 2026-08-29 (UTC): 7 of 25 calls failed between 03:33 and 07:17, then 36 of 36 succeeded between 07:17 and 10:30. Failures and successes interleave in the same process seconds apart — e.g. 06:36:01 success, 06:37:03 failure, 06:44:49 success. This is just one example from our logs, it's been happening for a while now (weeks at least)

Response body:

{"error":{"code":"InvalidRequestBody",
 "message":"Blocklist with name *REDACTED* not found, index = 0 | Request Id: 4f02f96e-58d5-4038-bc54-d3bca78384ad, Timestamp: 2026-08-29T07:16:49Z.",
 "details":[]}}

We verified after the fact that the blocklist exists on the resource.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

@Stefan Fleck I hope you are doing well,

What you are describing is a known behavior related to distributed cache replication on the backend inference nodes rather than an issue with your .NET code or request construction.

Because 400 is classified as a non-retryable client error, the SDK drops the request immediately instead of retrying against an alternate node.

Implement a Custom Retry Policy in the .NET SDK: You can hook a custom HttpPipelinePolicy into ContentSafetyClientOptions to catch HTTP 400 responses specifically containing "Blocklist with name" and retry the call 1–2 times with a short backoff (e.g., 200–500ms). This will allow the retry request to route to a healthy node without bubbling an exception to your application.
Report the Node Desync via Azure Support: Because your blocklist has existed for weeks without modification, persistent intermittent failures across weeks indicate a stuck replica or unhealthy instance in that region's cluster. I'm going to scale this thread so MS can take a look.

References:

Use custom blocklists in Azure AI Content Safety

Azure SDK for .NET - Customizing HTTP Pipeline and Retries

If this answer helped clarify the platform capabilities and save you troubleshooting time, please consider marking it as Accepted. This helps others in the community find similar solutions.

Stefan Fleck 20 Reputation points

2026-09-01T07:19:37.8466667+00:00

Thanks for the quick answer, the suggested solution is more or less what we are trying now. our company plan does not cover technical support, that's why i submitted the inquiry here rather than via azure support.