Fabric Copy Job Timeout

Hi joel_delima​,

I would be a little careful about treating the ~40-minute failure as a documented Copy Job timeout.

Microsoft does support SQL Server through an on-premises data gateway for Copy Job, including Full, Incremental and CDC scenarios, so the architecture itself is valid.

The error:

System.TimeoutException
Dispose resource timeout
Source=Microsoft.DataTransfer.DataContracts

does suggest the transfer/gateway path is timing out or failing to release a resource, but I could not find a Microsoft document that defines a fixed 40-minute timeout for Copy Job.

Given that only the first 100M+ row load fails, I would check:

1. Gateway CPU, memory and connection usage during the run.
2. Whether the gateway is on the latest supported version.
3. SQL Server query duration and blocking while the initial full read is running.
4. Whether the failure consistently happens at the same elapsed time or only under heavy gateway load.

For a table this large, I would also consider doing the initial load with a Fabric Pipeline Copy activity instead of Copy Job.

The SQL Server Copy activity supports query timeout and source partitioning including dynamic-range partitioning for parallel reads.

A practical pattern would be:

initial 100M+ row load
-> Pipeline Copy activity with partitioned reads

then

ongoing changes
-> Copy Job CDC / incremental copy

That gives you more control over the expensive first load while still keeping the simpler incremental process afterward.

If the job still fails at roughly the same point with low gateway CPU/memory and no SQL blocking, I would capture the Copy Job run ID, gateway logs, exact timestamp and full exception and raise a Fabric support case.

I would not start modifying undocumented gateway timeout settings unless Microsoft Support specifically recommends it.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.