ADX streaming ingestion failures for non-streaming tables

It seems that you are encountering an issue where Azure Data Explorer (ADX) is registering streaming ingestion failures for tables that have streaming ingestion disabled. The error code Kusto.DataNode.Exceptions.StreamingIngestionPolicyNotEnabledException indicates that the ingestion process is attempting to use streaming ingestion on these tables, which is not allowed since streaming ingestion is disabled.

Here are a few steps you can take to troubleshoot this issue:

1. Verify Table Configuration: Double-check the configuration of your tables in ADX to ensure that streaming ingestion is indeed disabled. You can do this by reviewing the table properties in the Azure portal or using Kusto queries to confirm the ingestion policy settings.
2. Check ASA Job Configuration: Review the output configuration of your Azure Stream Analytics jobs. Ensure that the output is correctly targeting the tables that have streaming ingestion disabled. If the output is configured to use streaming ingestion, it may lead to these errors.
3. Review Logs: Look into the logs for your Azure Stream Analytics jobs and ADX to gather more context on the ingestion attempts. This may provide insights into why the jobs are attempting to perform streaming ingestion on the specified tables.
4. Contact Support: If the issue persists after verifying the configurations and reviewing logs, consider reaching out to Azure support for further assistance. They can provide more detailed insights into the ingestion process and help identify any underlying issues.

By following these steps, you should be able to identify the cause of the streaming ingestion failures and address the issue accordingly.

Hi Javier Huamani,
Thank you for reaching out to Microsoft QA!
You’re seeing these errors because something is trying to send data to your ADX tables using the streaming ingestion path, while streaming ingestion is turned off for those tables/databases. When that happens, ADX rejects the request and records a StreamingIngestionPolicyNotEnabledException in .show streamingingestion failures.​

In your setup, the Stream Analytics jobs are intentionally using batch ingestion only, with the ingestion batching policy inherited from the database, so disabling streaming ingestion is correct. What seems to have changed after the cluster version deployment is that some of the traffic from ASA (or another client) is now being routed through the streaming path by mistake, which is why you suddenly see these failures even though you never enabled streaming ingestion on those tables.​

To narrow it down and fix it:

In ADX, confirm the policy really is disabled where you expect it:

Run .show database <db> policy streamingingestion and .show table <table> policy streamingingestion and check that IsEnabled is false.​

In each ASA job, open the ADX output and double‑check:

You’re using the standard Azure Data Explorer output (not any special streaming option).

The table name and schema (column names, types, and casing) match exactly what’s defined in ADX.​

Use .show streamingingestion failures project LastFailureOn, Database, Table, IngestionSource, PrincipalIdentity, ErrorCode, Details to see who is sending the streaming requests and from which source.​

If it’s the ASA managed identity, there may be a misconfiguration or retry path that is choosing streaming.

If it’s another app or pipeline, that component is the one to reconfigure.

If you don’t need streaming ingestion at all and regular ingestion is working, these errors don’t mean your batch ingestion is broken; they just indicate unwanted streaming attempts. The clean solution is to find and fix the client that’s issuing those streaming calls so the metric stops increasing.

If later you decide you actually want streaming ingestion for those tables, you would need to explicitly enable the streaming ingestion policy on the cluster and on the relevant database/table, then point ASA to use that mode.

I hope this helps you get back on track with your ingestion tasks! If you have any other questions or need further assistance, feel free to ask.