Queue items stop adding to queue randomly

Hello,

I have a Google Sheet with about 170K rows. I read that sheet and output that into a data table, which then loops through row by row and adds each row to the Orchestrator queue. This has failed twice on me now. The first failure the bot added about 80K items to queue and decided to throw the “catch” in the “try/catch” activity where it says “nothing was added to queue”. The second time this failed, it only made it to about 4K items before throwing the BusEx in “catch”.

I’ve never experienced this failure when adding items to queue. Does anyone know what I might be doing wrong? I use this same logic for all our other bots.

Thanks!

@Josh_James
you can figure out by checking row data where it has failed. Might be possible something is wrong in that row.

Possibly… shouldn’t it have failed at row 4K the first time though? It made it all the way to 80K on the first try, then the second try only to row 4K. Wouldn’t it have caught the bad row at 4K on the first pass?

@Josh_James what is the error, did you figure out by printing exception

Currently running a test in Dev, waiting for the error to appear. In Production, the error was the BusEx message I have in the “catch” of the “try/catch” activity, which is “Nothing was added to queue”.

@Josh_James In dev you should run without try catch so that we figure what is exact exception

I’m already 4900 into it. If I can’t get an exact exception on this try, I’ll do another one without try/catch.

1 Like

@Josh_James And you can put Retry as well.

Would “retry” start adding to queue from the beginning of the data table? I wouldn’t want to have duplicates.

@Josh_James No, just put "Add items to queue " activity inside Retry. It will retry on particular fail case.

1 Like

Woohoo! I believe you are correct. I got to 32K, then it failed with an “object reference not set to an instance of an object” error. Nothing looked wrong. I hit “retry current activity” in the debugger, and it continued on just fine! So yes, I will add a “retry” activity where you suggested.

Thank you!!

1 Like

@Josh_James so we can’t ignore the significance of Retry. It really helps when all the data/logics fine but code don’t perform accurately. you can put retry number as 3. if incase of 2nd failure it will retry third time.

1 Like

Why aren’t you using the Bulk Add Queue Items activity? Then you don’t need to loop and make all these individual connections to Orchestrator.

I’ve never tried that activity. I just looked at the doc for this activity on the UiPath doc page. It looks like this activity only supports 15000 lines. I need to add 175K. Thank you for the suggestion, though. Maybe this will be useful with other processes.

1 Like

You could easily break it into multiple 15k chunks, still massively reducing the number of individual connections to Orchestrator.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.