Fabric DirectLake Refresh Failing

[kadams8844]

We have been working with Fabric for a few months now.  Recently, we have been stress-testing the DirectLake functionality with a larger set of data (a single table that's ~230 million rows).  The issue we have seen is that the semantic models are throwing framing errors and after a certain number of failures the auto-refresh turns off.

From the Lakehouse we created a custom semantic model and made sure it was set to automatically refresh.  After some time we'd start seeing the following error:

Image:

Text:

Power BI Premium Backend Error:

An error has occurred while framing the dataset 9f8a131a-01ff-45ec-856f-9e3115f4be53, error: System.IO.InvalidDataException: The 'x-ms-xmlacaps-negotiation-flags' header is missing from the HTTP response! at Microsoft.AnalysisServices.HttpStream.PaasInfraController.ProcessWebResponse(HttpStream owner, Object context, WebResponseInfo response) at Microsoft.AnalysisServices.HttpStream.HttpChannelController.CompleteHttpClientBasedOperation(HttpStream owner, Object context, Task`1 pendingResponse) at Microsoft.AnalysisServices.HttpStream.HttpXmlaOperation.HttpClientOperationManager.GetResponse(HttpXmlaOperation operation) at Microsoft.AnalysisServices.HttpStream.PaasInfraController.PaasInfraXmlaOperation.EnsureCanRead() at Microsoft.AnalysisServices.HttpStream.HttpXmlaOperation.GetResponseDataType() at Microsoft.AnalysisServices.HttpStream.GetResponseDataType() at Microsoft.AnalysisServices.CompressedStream.GetResponseDataType() at Microsoft.AnalysisServices.XmlaClient.EndRequest(Boolean useBinaryXml) at Microsoft.AnalysisServices.XmlaClient.CreateSession(ListDictionary properties, Boolean sendNamespaceCompatibility, String sessionToken) at Microsoft.AnalysisServices.XmlaClient.Connect(ConnectionInfo connectionInfo, Boolean beginSession) at Microsoft.AnalysisServices.Core.Server.Connect(String connectionString, String sessionId, ObjectExpansion expansionType) at Microsoft.AnalysisServices.Core.Server.Connect(String connectionString) at Microsoft.ASWL.Service.Engine.SeethruAutoSync.SeethruAutoSyncManager.<InvokeFramingAsync>d__32.MoveNext() in /_/ASWL.Service/Engine/SeethruAutoSync/SeethruAutoSyncManager.cs:line 499.

These would continue and then eventually the auto-refresh slider would turn off.

We have a single workspace associated with the Fabric capacity.  This is a sandbox environment so rather than have the capacity up all the time we created a data factory pipeline to pause the capacity at night.  Restarting the capacity is a manual activity.

Our initial thought is that turning the capacity off at night is somehow corrupting the semantic model.  You can re-enable the auto-refresh, make updates to the table, and then see that reflected in the report.  After some time though the framing errors start again and eventually (after 30 or so framing error failures) the auto-refresh flips off.

Has anyone else seen this behavior or have any thoughts as to what is happening?  We went as far as creating a new Lakehouse with the same table along with a custom semantic model.  We turned off the data factory trigger for the pipeline that was pausing the Fabric capacity each evening.  Over the last week this dataset has refreshed without error and there are no framing errors.

I'm happy to supply more details but am looking for more confirmation that managing the capacity this way can be harmful to DirectLake models.  Our subscription is pay-as-you-go so leaving the capacity running all the time doesn't make sense.

Thanks.

[Corar]

Hi we are seeing the same behaviour and are not even able to turn the refresh back on.

We are turning of the capacity over night, so that wa also my first assumptions.

Did you ever find a solution for that problem?

[kadams8844]

We did not find a solution and ultimately didn't open a ticket.  We observed the behavior when trying to turn off/on the capacity.  We tested another dataset over the course of a couple of weeks where we did not turn off/on the Fabric capacity.  The issues noted in my original post went away which reinforced our initial thoughts that managing the Fabric capacity that way causes some level of corruption with model.

[lbendlin]

I would strongly suggest to open a ticket on this.  That stuff has to work.

[lbendlin]

If you have a Pro license you can open a Pro ticket at https://admin.powerplatform.microsoft.com/newsupportticket/powerbi
Otherwise you can raise an issue at https://community.fabric.microsoft.com/t5/Issues/idb-p/Issues .