Notebook randomly failed with error SSL: UNEXPECTED_EOF_WHILE_READING

[KZ_DevOps]

My python notebook (exec every 3 min via pipeline) pereodically (1-2 times per 1-2 day) failed with the following error. 

SSLError: HTTPSConnectionPool(host='[eventhouse-id].z4.kusto.fabric.microsoft.com', port=443): Max retries exceeded with url: /v2/rest/query (Caused by SSLError(SSLEOFError(8, '[SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1016)')))

Notebook has retry logic in case of such failures, and most of the time 2nd job (initiated by retry logic) executes successfully. Notebook execution usually 1-2 min max. 

From the error looks like something happened inside of MS Fabric. Could you please advise if you ever had similar issues, is it possible that issue related to transient failures ?

[stoic-harsh]

Hi @KZ_DevOps,

Transient SSL errors occur when the Fabric/Kusto backend temporarily closes or resets connections (load balancing/short network blips).

What you are already doing is the right workaround. To improve further, I would suggest to:

• Use retries with exponential backoff, where each retry waits progressively longer (for example, 2s for 1st retry, 4s for 2nd, then 8s and so on), instead of retrying immediately, reducing pressure on the service.
• Monitor frequency, and escalate to support if the errors become persistent.

In short, it is a known observation and no code or setup fault.

[v-sshirivolu]

Hi @KZ_DevOps ,
This issue is very likely due to temporary connectivity or service side disruptions within Microsoft Fabric / Kusto, rather than any defect in the notebook logic itself. The SSL: UNEXPECTED_EOF_WHILE_READING error generally occurs when the Fabric/Kusto service unexpectedly terminates a TLS connection, which can happen during short-lived backend events such as service restarts, capacity scaling, or internal network routing changes. A strong indication of this transient behavior is that the notebook typically completes successfully when retried. To address this, it is recommended to retain and slightly enhance the existing retry mechanism by applying exponential backoff with brief delays, ensure that each notebook execution establishes a fresh HTTP/TLS connection instead of reusing long lived sessions, and, where feasible, introduce a small random offset to the pipeline schedule to reduce the likelihood of recurring timing collisions. No adjustments to SSL settings, Python versions, or certificates are necessary, as this is a known and expected behavior for high frequency workloads interacting with Fabric services.

[v-sshirivolu]

Hi @KZ_DevOps ,

I hope the information provided above assists you in resolving the issue. If you have any additional questions or concerns, please do not hesitate to contact us. We are here to support you and will be happy to help with any further assistance you may need.

[KZ_DevOps]

Thank you for your promt responce. But does it mean that such type of issues (Transient errors) are expected ? And technically we cannot do anything on our end to avoid such issues ?

[v-sshirivolu · Accepted solution]

Hi @KZ_DevOps  ,
Transient errors are common in cloud platforms like Microsoft Fabric and may occur due to temporary backend or network conditions. These cannot be fully avoided from the client side, and there are no SSL or notebook configuration changes that will prevent them. The recommended approach is to implement retry logic with exponential backoff and monitor error frequency.

Microsoft documentation references:

Fabric Notebooks troubleshooting guide - Microsoft Fabric | Microsoft Learn

Troubleshoot the Warehouse - Microsoft Fabric | Microsoft Learn
Troubleshoot connectors - Microsoft Fabric | Microsoft Learn