ADF issue in running Scope activity

Balaji Krish 0 Reputation points Microsoft Employee
2026-07-08T21:47:00.1+00:00

n Azure Data Factory, I have setup a Pipeline that runs a Scope script activity against Asimov VC to aggregate data. I am finding that the activity is failing whenever it runs for more than 3 hours+. The activity error I see is 

Error code

BadRequest

Failure typeUser configuration issue

Details

Operation on target TBP failed:  

Activity ID

c031b11a-f69d-491e-9e55-639517a7b0e3 

In ADF I have the activity timeout configured for 12 hours. So looks like some cosmos related timeout is happening in when running the scope activity. I couldn't find any meaningful way to troubleshoot. 

Azure Data Factory
Azure Data Factory

An Azure service for ingesting, preparing, and transforming data at scale.


1 answer

Sort by: Most helpful
  1. Ravi Kiran Pagidi 170 Reputation points
    2026-07-13T02:50:58.5366667+00:00

    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:

    1. 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
    
    1. 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.
    2. If this is calling an internal VC/service through ADF, confirm whether that service has its own max execution/session timeout around 3 hours.
    3. Add ADF retry only if the operation is idempotent. Otherwise retries may duplicate output.
    4. 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.
    5. 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.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.