An Azure service for ingesting, preparing, and transforming data at scale.
Hi Balaji,
The 12-hour timeout in ADF only controls the ADF activity policy. It does not always override timeout limits in the downstream service that the activity is calling.
Since the failure happens only when the Scope job runs for more than 3 hours, I would first treat this as a downstream Scope/Asimov VC execution timeout or service-side limit, not a normal ADF pipeline timeout.
Please check the following:
- Open the failed activity in ADF Monitor and expand the full input/output JSON. Sometimes the inner error is available there even when the UI only shows
BadRequest.
Check the Scope/Asimov job execution logs using the Activity ID and UTC timestamp:
c031b11a-f69d-491e-9e55-639517a7b0e3
- If the same script consistently crosses 3 hours, try splitting it by smaller time windows/partitions, for example hourly or daily slices, and run them through a ForEach pattern.
- If this is calling an internal VC/service through ADF, confirm whether that service has its own max execution/session timeout around 3 hours.
- Add ADF retry only if the operation is idempotent. Otherwise retries may duplicate output.
- If possible, change the pattern to submit the Scope job asynchronously, then poll the job status from ADF instead of keeping one long-running synchronous activity open.
- In short, the ADF timeout setting looks fine, but the failing component is probably the Scope/Asimov execution path. I would collect the full activity output and backend job logs, then either split the workload or move to an async submit-and-poll pattern.