Forum Discussion
Gen2 Dataflow (CI/CD)
I am facing refresh error in my Fabric pipeline. Irony is i am facing this error only for 3 APIs out of 5 APIs. Other 2 APIs working fine. I tried one troubleshooot by replacing symbols like "." from the field name to "_". but no use. Can some one provide a rock solid solution for this issue. PS- all 5 pipelines were working fine for weeks. out of no where the error started to appear in last 5 days.
WriteToDataDestination: There was a problem refreshing the dataflow: "Couldn't refresh the entity because of an issue with the mashup document MashupException.Error: Error in replacing table's content with new data in a version: #{0}., Underlying error: The operation has timed out Details: Reason = DataSource.Error;ErrorCode = Lakehouse036;Message = The operation has timed out;ErrorCode = 19005;Microsoft.Data.Mashup.Error.Context = User GatewayObjectId: xxxx-xxxx-xxxx-xxxx-xxxx". Error code: 104100.
jp_here2026
This is issue more probably due to increase in datasize.
and the problem occurs when you try to write this into lakehouse.
Steps to follow:
1-To confirm this only try to limit the load of data like first 100 rows for eachTable.FirstN(Source,100)If this solve the issue it means you have data limitation constraint.
if not then it means it is definitely related to Schema or Fabric Related issue.
2- Next recommendation is try to write data for failed piplines in another lakehouse or in another warehouseThis helps to identy whether the problem is with the source or destination,
further write to in a new table, if succeed then it means you need to create new Delta tables in lakehouse.
Check the fabric capacity size.My suggestion:
- Lakehouse write timeout due to increased data volume or slower writes- Most Likely
- Recent Microsoft Fabric backend issue/regression, Most likely
- API response has changed (size or schema) due to schema drift.-Less Likely coz pipelines were working previously.
- Corrupted Delta Table metadata, need to create new table.- Less Likely
If this helps, ✓ Mark as Kudos | Help Others
6 Replies
Hi jp_here2026 ,
The Lakehouse036 / 19005 – operation timed out is a write-side timeout at the Lakehouse destination, not a schema/field-name issue — that's why replacing . with _ didn't help. The 3 failing APIs are most likely the ones with larger or growing payloads, and the Replace write is timing out.
Try in this order:- Change destination update method from Replace → Append (with an incremental key) for the 3 heavy APIs.
- Disable staging on those queries if not needed.
- Split the 3 failing APIs into a separate Dataflow so they don't share compute with the working ones.
- Add server-side filters/pagination at the API ($filter, $top, date window) to reduce payload.
- Recreate the destination table for one failing API as a test — Delta table state can go stale after weeks of Replace.
If it still fails, check these:
- Gateway health (your error shows a GatewayObjectId) — CPU/RAM and logs.
- Row count/size difference between the 3 failing vs 2 working APIs.
- Fabric Capacity Metrics app for throttling during the refresh window.
- Whether it fails at a consistent duration (indicates a hard timeout).
References:
If this got you what you needed, a Kudos and an Accepted Solution mark would be great — it helps others searching for the same thing find the answer quicker.
Dev_Dholakia Thanks for suggestion, i tried to Limit first 100 records, the flow works fine. I beleive this is fabric capacity error.
hi jp_here2026 ,
Glad the First 100 test confirmed it — as the accepted solution already covered, this is a Lakehouse write timeout driven by data volume, not a schema issue.
Just adding a couple of practical follow-ups for anyone hitting the same:
- Move to Incremental Refresh / Append instead of full Replace — full loads will keep failing as data keeps growing. This is the real long-term fix.
- For the initial historical load, use a Pipeline Copy activity → Lakehouse (it's much faster and doesn't hit mashup timeouts), then let the Dataflow handle only the daily delta.
- Check the Fabric Capacity Metrics app during the failing window — if you see smoothing/overload, scaling up the SKU briefly for one clean full load usually gets you unblocked.
- Pull data from the API in chunks (date range / pagination) rather than one big pull, if the source supports it.
Disclosure: My earlier response above was drafted with the assistance of an AI tool (Microsoft Copilot) and cross-checked against Microsoft Learn documentation. Sharing this note for transparency as per the Community AI Usage Policy
jp_here2026
This is issue more probably due to increase in datasize.
and the problem occurs when you try to write this into lakehouse.
Steps to follow:
1-To confirm this only try to limit the load of data like first 100 rows for eachTable.FirstN(Source,100)If this solve the issue it means you have data limitation constraint.
if not then it means it is definitely related to Schema or Fabric Related issue.
2- Next recommendation is try to write data for failed piplines in another lakehouse or in another warehouseThis helps to identy whether the problem is with the source or destination,
further write to in a new table, if succeed then it means you need to create new Delta tables in lakehouse.
Check the fabric capacity size.My suggestion:
- Lakehouse write timeout due to increased data volume or slower writes- Most Likely
- Recent Microsoft Fabric backend issue/regression, Most likely
- API response has changed (size or schema) due to schema drift.-Less Likely coz pipelines were working previously.
- Corrupted Delta Table metadata, need to create new table.- Less Likely
If this helps, ✓ Mark as Kudos | Help Others
Murtaza_Ghafoor Thanks for the idea. I tried with First 100, where the dataflow Works and data stored in Lakehouse. But if i tried with entire data it throws timeout error.
jp_here2026
The next step would be check the capacity throtlling issue from fabric metric capacity apps.
If the issue is with capacity sizing then you need to increase the capacity.
Other option would be implment CDC incremental load that will not choke the capacity.
If this helps, ✓ Mark as Kudos | Help Others
