Forum Discussion
Advocate IIDatafow Gen2: inconsistent behavior/fails and CU consumption
Hi chris__1 , Joshrodgers123
This particular failure (calling /workspaces and receiving 429) is happening due to an internal throttling issue that has been resolved since beginning of this week.
Please monitor these refreshes for a bit and see if you continue to observe failures due to "429" error. If so, let me know and sharing the session\request\dataflow ID from the refresh history screen:
Memorable MemberThank you for stating what everyone faced with 104100 errors and other DFg2 shenanigans should be hollering from the rooftops. I sure am. But get this: support just got back to me yesterday and told me that the workaround to handle error 104100 (when ingesting from an on-prem DB) is by design (according to the internal team, whoever they are)! Meanwhile, if you try to do your ingest using only one DFg2, you will be blocked by a 104100 error! How is that by design and not a bug fro crying out loud!?
Advocate VI'm not sure I understand your reply. What did support say was the workaround and what did they say was by design?
- Element115
Support said this section 'Workaround: Split dataflow in a separate ingest and load dataflow' on this page of the Micrsofot documention On-premises data gateway considerations for data destinations in Dataflow Gen2 - Microsoft Fabric | Microsoft Learn, is the workaround and it's by design supposedly that we can't use just one DFg2 when ingesting from an on-prem DB. Just when you think you've heard everything... 😁