This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(291.2, 6%, 38%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKR%3C/text%3E%3C/svg%3E)
I have one pipeline calling the other. Post that, the parent pipeline waits for the completion of the pipeline. Here it calls the REST API providing the run id of the child pipeline. At times, I see that this call is timing out, with the following error message :
Error calling the endpoint 'https://management.azure.com/subscriptions/xxx/resourceGroups/yyy/providers/Microsoft.DataFactory/factories/zzz/pipelineruns/c9c51bd0-5c61-4a62-b220-df253faa829f?api-version=2018-06-01'. Response status code: 'RequestTimeout'. More details:Exception message: 'A task was canceled.'. Url endpoint request timed out. Please make sure the endpoint response is within 1 minute and retry.
Can you please let me know why this is happening and how can it be avoided.
Couple of points to note :
Thanks @MartinJaffer-MSFT .... I introduced an ARM template parameter and used that to set the retry count for all the applicable activities, thanks.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(172.8, 70%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMM%3C/text%3E%3C/svg%3E)
That's a great solution. Wow, I'm really off my game this week. I'll convert you comment to answer.
No problem :)
Thank you @MartinJaffer-MSFT for the details. Would increasing the retry count solve this problem ?
I expect increasing the retry count would solve the problem, and in a much simpler way than I gave above!
Thank you for noticing and reminding me about the retry count. I forgot it existed, like how scenery becomes familiar and no longer something one takes notice of.
I speculate that the cause is some time-lag of the run being updated. If the retry does not help, this disproves my theorey.
Thanks @MartinJaffer-MSFT . I was trying to refine a global variable for the retryCount and use it in all pipelines. However, I do not see a way to provide this value dynamically. Is it that I have to hard-code this value, and cannot read from a global variable ?
I do not want to hard code the retry count value. Because, if this value changes, I do not want to go change all pipelines individually. Want to have a global retry count value and use that global parameter across all pipelines.
@Kothai Ramanathan I tried replacing the retryCount with an expression, however this threw an error. At this time, the retryCount must be a whole number, and cannot be an expression, even if the expression references a whole number.
This does sound like a useful thing to be able to do. Can you go to the feedback forum and submit it as a feature request?
Since going back and changing all pipelines manually is a pain, we can write a script to do that for us.
Before writing a script, there are some things we need to know:
@Kothai Ramanathan to help others , could you please mark the appropriate answer as accepted?
Hello @Kothai Ramanathan and welcome back to Microsoft Q&A.
Given that the failure rate is 1%, the simplest solution is to add in a redundancy like shown below. This would reduce failure rate to 1% of 1% (0.01%).
In this diagram there are two web activities and a wait activity. The web activities are two attempts on the call which times out. The wait activity is a placeholder for whatever comes afterwards.
The first web activity (attempt1) is connected to the second web activity (attempt2) by a red on-failure dependency.
The first web activity (attempt1) is connected to the wait activity by a blue on-completion dependency.
The second web activity (attempt2) is connected to the wait activity by a green on-success dependency and a grey skipped dependency.
If the first web activity fails or times out, then the second web activity runs.
If the second web activity fails or times out, then the wait activity does not run, and the pipeline fails.
If the second web activity succeeds, then the wait activity runs and the pipeline succeeds.
An investigation into why the call times out requires a deeper look than I can provide here. If you still want a root cause analysis, let me know and I can give you a 1-time free support ticket.