I was running a background task using the Queue Background Task action in my logic block. I noticed in the Jobs application that there was a failed background task and then after a few seconds, another background task ran and this time it went successfully. I wonder if the background task has a built in retry mechanism when it encounters an error or maybe there is something else in my logic block that was causing an issue.
To my knowledge, background task jobs do not have any built-in functionality for them to automatically retry.
2 Likes
Ian is correct - while there are other processes that will automatically retry after a failure or timeout (like workflow Autotransitions), the background task and its logic will run exactly once regardless of outcome.
An individual record in the Jobs application can give you any information the background logic captured, so a failed job will have the associated error message(s) and any log data associated with them.
1 Like
Ross and Ian are right, and also not exactly right. There is one scenario where you would see a Background Task Job not complete and “retry”. You can tell if your Job did so based on the Adoption Count field in the Job’s app. Overwhelmingly you’ll find this value to be zero. A zero means the job ran until it reached a terminal status (success/warning/failure/stopped/etc).
In the rare case when that value is not zero - something has gone very wrong. A batch server has run out of memory or has failed health checks repetitively (pegged CPU, no connectivity, others) and been taken out of service or something similarly catastrophic. In that case any jobs that were running on that server are, obviously, no longer running. They will no longer be updating the job’s ‘alive’ marker and will be noticed by the system as orphaned. Once identified as an orphan the batch framework lets the job type decide how to handle the orphan. The orphan behavior for the Background Task job type is to re-run the job with the original inputs.
That is the only kind of automatic “retry” you’ll see.
3 Likes
Thank you all for the information. In my case, the failed job has an adoption count of 0. However, somehow I am seeing two background tasks being kicked off within a second apart. So one of the job eventually failed due to timeout on a table lock.
I wonder if it is the way I set up the input/output table for my background task. Here is my setup:
- I have an integration table A with post-insert trigger to call logic block A.
- Logic block A at some point will call a background task action, which is logic block B.
- Logic block B’s input and output table is table A.
Observation:
- If I use postman to insert a record into table A, I will see just one instance of background task running and getting completed after one minute.
- If I run an application with row action linked to logic block A, it will launch the background task logic block B and I saw single instance running and getting completed.
- However, if the record is inserted via some integration code, then I see more than 1 background task running within a second. Note that I check the integration table A after seeing multiple background tasks running and I see only one record inserted into table A. That means there should be just one integration request inserting a record into table A.
Here is the submitted and modified datetime and job status:
Ah, sorry, I realize there are two records written to the integration table A for some reason. I think it might be two servers (development and integration) processed the same event and it ended up creating two identical records into table A. Thanks for all your help.
2 Likes