Forum Discussion
Helper ICan't access/query dataflow table due to surge protection
Today i came a cross another bug related to surge protection in Fabric. Some of my models we're receiving the "Expression.Error: The key didn't match any rows in the table.." error during refresh and while accessing a dataflow table. The dataflow is in capacity that had surge protection active at the time but the models aren't.
I also wasn't able to access/query the dataflow tables through power bi desktop (i have admin access), it only showed the dataflow name in the list. To fix the "problem" earlier i changed the surge protection thresholds and a few minutes later i was able to see the dataflow table through power bi desktop and the models refreshed again.
I digged thought the model past refreshes and saw the same problem on monday (but nobody complained). Is this a new expected surge protection behavior? (Any microsoft recent updates on this?) Did anyone also came accross this problem?
Last year i had a different problem with SP but on report visual render (https://community.fabric.microsoft.com/t5/Service/quot-Background-Rejection-quot-blocking-report-access-load/m-p/4779921) that made me disable it on all of my capacities.
Hello gabrielPerson,
What you observed may actually be related to the documented surge protection behavior rather than the semantic models themselves.
Microsoft's current surge protection documentation states that when the configured background rejection threshold is reached, new background operations are rejected. It also specifically mentions that some requests initiated from the Fabric UI are billed as background operations, or depend on background operations to complete, and can therefore be rejected while surge protection is active.
That could explain why the Dataflow was visible but its tables could not be enumerated in Power BI Desktop, and why downstream model refreshes returned "The key didn't match any rows in the table". My interpretation is that the connector may have failed to retrieve the expected Dataflow entity metadata while the required operation was being rejected.
I would still be careful about calling the exact "key didn't match any rows" error expected behavior, because I could not find Microsoft documentation that explicitly maps this specific Power Query error to surge protection.
However, the timing you described is a strong indicator: surge protection was active, the tables were inaccessible, and after changing the thresholds and allowing the capacity to recover, the tables became visible and the model refreshes succeeded again.
I would check the Capacity Metrics app under Compute > System events for SurgeProtectionActive during the exact failure timestamps. I would also compare the Background rejection chart for the same period. Microsoft documents both as the recommended way to confirm when surge protection became active and background operations were being rejected.
If the timestamps align, I think you have a good correlation between surge protection and the Dataflow access failure. The remaining question for Microsoft would be whether Power BI Desktop should surface a clearer capacity/rejection error instead of presenting the secondary Power Query "key didn't match any rows" message.
Microsoft reference:Surge protection in Microsoft Fabric
Fabric Capacity Metrics app Compute page
Best regards,
Omkar Shinde
Microsoft Fabric Enthusiast | Power BI Consultant
💡 If you found this response helpful, please consider giving it a Kudos.
✅ If this resolves your question, please mark it as the Accepted Solution to help others in the community.
3 Replies
- Omkar_1712
Solution Specialist
Hello gabrielPerson,
What you observed may actually be related to the documented surge protection behavior rather than the semantic models themselves.
Microsoft's current surge protection documentation states that when the configured background rejection threshold is reached, new background operations are rejected. It also specifically mentions that some requests initiated from the Fabric UI are billed as background operations, or depend on background operations to complete, and can therefore be rejected while surge protection is active.
That could explain why the Dataflow was visible but its tables could not be enumerated in Power BI Desktop, and why downstream model refreshes returned "The key didn't match any rows in the table". My interpretation is that the connector may have failed to retrieve the expected Dataflow entity metadata while the required operation was being rejected.
I would still be careful about calling the exact "key didn't match any rows" error expected behavior, because I could not find Microsoft documentation that explicitly maps this specific Power Query error to surge protection.
However, the timing you described is a strong indicator: surge protection was active, the tables were inaccessible, and after changing the thresholds and allowing the capacity to recover, the tables became visible and the model refreshes succeeded again.
I would check the Capacity Metrics app under Compute > System events for SurgeProtectionActive during the exact failure timestamps. I would also compare the Background rejection chart for the same period. Microsoft documents both as the recommended way to confirm when surge protection became active and background operations were being rejected.
If the timestamps align, I think you have a good correlation between surge protection and the Dataflow access failure. The remaining question for Microsoft would be whether Power BI Desktop should surface a clearer capacity/rejection error instead of presenting the secondary Power Query "key didn't match any rows" message.
Microsoft reference:Surge protection in Microsoft Fabric
Fabric Capacity Metrics app Compute page
Best regards,
Omkar Shinde
Microsoft Fabric Enthusiast | Power BI Consultant
💡 If you found this response helpful, please consider giving it a Kudos.
✅ If this resolves your question, please mark it as the Accepted Solution to help others in the community.
gabrielPersonHi Omkar_1712 thanks for the explanation. Indeed it seems like a expected behavior from rejection to block the dataflow metadata load even if its'n explicit in the docs. I double checked the error against the surge protection timestamp and had the same problem. I'll report it to my users.
v-sathmakuriCommunity Support
Hi gabrielPerson ,
Thanks for reaching out to fabric community.
Could you review the suggestion provided by Omkar_1712 and let us know if you have any additional questions, we are happy to address.
Thanks!!