[Issue #513] Script freezes unexpectedly with no error written to log. Manual pause/resume brings it back

Hi @tday,

In case you haven’t hear back regarding your question

According to an earlier post here, reach out to them via the contact us form to arrange sending the video you created.

I’m among the affected users and except for this one glitch, UI.Vision (Kantu) has been great! So I hope they find a solution soon.

Cheers

I encounter this issue everyday and a colleague of mine found a workaround. Hopefully, this points you in a direction towards a solution.

My script goes like this:

  1. Open a CSV file
  2. Read column data into variables
  3. Click Link Tab 1 on page
  4. Search something (col1)
  5. Click Link Tab 2 on page
  6. Update something (col2, col3, …)
  7. Done

I use the Play Loop to run through the rows of data (e.g., Start Value: 3, Max: 42)

We run the “play loop” for this script maybe 5-10 times every single day. I could have a loop of 50 and it goes without ever stopping. I could have a loop of 3 and it will stop at loop 2.

What we’ve noticed lately when it stops is that by simply clicking the tab again, Kantu wakes up and continues (Pause, Resume doesn’t seem to work anymore). So if I can see the script stopped in step 4, I’ll just click on Link Tab 1 and the script wakes up and continues. If the script stopped in step 6, I’ll just click on Link Tab 2 and it wakes up and resumes on its own.

Of course, what I’m really saying is we can’t trust it to run unattended, which defeats the entire purpose of automating. So it’s a big thorn on the beauty of UI.Vision. I’m actually expanding my code to include error handling. That will at least help me identify where it stopped.

It seems that it has to do with the load time of the page somehow. We have 3 sets of scripts. All of them, we run via Play Loop.

The two of them go through quite a bit of steps (1-7 above is oversimplified). There’s several “clickandwait” so it’s more often prone to randomly stopping in the middle.

The third one is very straightforward. One “clickandwait” to get to the page. Then on the same page, we click create, fill-in date, update. We loop 5 to 60 times to click, create, fill-in, update. It does still stop sometimes, but not anywhere near as often as a more complex cycle.

Let me know if you haven’t found any reproducable example. I could try to create a dummy website and write a similar script/csv/play loop to emulate what we’re doing in production. And hopefully be able to reproduce the issue and share it with your team.

I’ll just click on Link Tab 1 …

Can you post a screencast of this?

. I could try to create a dummy website and write a similar script/csv/play loop to emulate what we’re doing in production.

That would be even better than a screencast :wink:

There’s a lot of confidential information so I can’t do a screencast

I will try to create a website that will simulate what I do. And then see if I can reproduce the same issue.

Thank you for all your work! Although it happens to everyone, I know it’s difficult to reproduce. So I can reproduce it on a dummy website, even I would be very happy. It may seem that the clickandwait could be the culprit. Because when I say “Click Tab 1,” it’s essentially telling Kantu, “hey I’m on the tab/link that you’re waiting for” (even if I was already there). So Kantu seems to wake up and “oh, yeah, let me continue”. Or even simpler, there is activity on the browser and the kantu add-in has an interrupt that would always check if it has anything pending.

I guess until someone has a reproducable issue, we won’t really be able to tell. Hopefully, I get lucky.

I also happened to me that Kantu stops while loading a site with the command open, unfortunately to date I have not found any solution and happens randomly.
The slower the site to load and the more likely that Kantu will block and do not detect when the site is totally loaded and remain stucked.

@admin

Do you or your staff conduct long scrapes for internal use or testing?
Have you or your staff never encountered this?

If you do conduct long scrapes and have never suffered this issue, maybe your development environment is “over-optimised”, or maybe you could share it with us to see if we can reproduce your environment.

I’m just trying to understand what is different about your set-up to ours that you can’t reproduce it.

Screencasts are difficult because it occurs randomly.

1 Like
{
      "Command": "selectWindow",
      "Target": "TAB=OPEN",
      "Value": "${!COL18}"
}

This is the command that chokes my script most now. It’s been mentioned a few times in this thread recently.

@TheWhippinpost We have seen this issue before, and we are working on a fix for it. Which is very difficult because in every test case we have so far, the issue happens only “sometimes”.

Overall, the more test cases we have, the better. Because we assume this is not one issue, but several different ones, just with the same symptoms. So every test case we have will go into our test suite, so we can test potential solutions against it.

…This is the command that chokes my script most now. It’s been mentioned a few times in this thread recently.

Do you have a test case that we can run?

1 Like

@admin

Even to me it happened that this command remains locked and does not go on, depends on the loading of the page, if the page does not load in a short time kantu stops. I have had some freeze cases with this command but it depends on the page load and Kantu waiting for the page to be loaded to execute subsequent commands.

Does not always occur because it depends on the detection of the loading of the page by Kantu, usually after this error shows that Kantu is not connected to the tab, in this case you must open a new tab load a valid URL and restart macro

Do you have a test case that we can run?

As is so often the case here, it seems, I’d have to give you credentials to access the site; which doesn’t help either of us.

I have to say I don’t encounter this as much now. When I do it’s usually because I restarted Kantu (after it stalled) before closing the tab that was open.

1 Like

Hi @admin. Just a quick update on this issue.

When I was reading CSV rows using Play Loop the freeze issue wasn’t so bad. When I switched it from Play Loop to a while / endWhile, the problem got a lot worse (using v4.2.6).

But now some good news. With v5.0.1, the problem seems to be less frequent (or being hopeful, resolved?)

I’m not sure if you applied a fix specific to this issue. But the last 2 days, I’ve read through the following CSV files with zero freezes.

  • Jun 4 - 25, 3
  • Jun 5 - 18, 43, 14, 14, 5, 30

The above shows that in the last 2 days, I looped through 8 CSV files (each item shows the number of rows per file). Smallest was 3 rows, largest was 43 rows.

Before v5.0.1, I don’t recall a streak this long without any errors. So I’m eager to get feedback from others facing the same issue.

@william19 That is good news! Indeed, V5.0.1 contains some improvements for this issue, but it is not completey resolved. We are still working on it.

1 Like

@TheWhippinpost the issue you mentioned in [Fixed] ipcPromise: onAsk timeout 3000 for cmd "RUN_COMMAND" is probably a side effect of these fixes. That is why it would be great to get a test macro.

I’ve messaged you with links to screencasts.

Unfortunately I have faced the same issue today on V5. Only refresh of the page brought the macro back to life. :cold_sweat:

We know that the issue is only partially fixed in V5.0.1. But we plan to have a complete solution this month.

Hi, I have the same issue, after 20 to 30 loops the macro stops without error message, when refreshing the page, the macro starts working again. If it hangs on a pause command, the refreshing on the page doesnt work.

I tried executing a macro with 15 “pause” commands and 38 loops, the macro stopped at loop 26 with no error message, and refreshing the page didnt helped.

Something new here. Now I see a timeout. Not counting. And refresh of the page or pause/resume do not work.

Update on my post from last Jun 5th (post #52). I do get the freezing again. And quite often. I will switch storeEval to excecuteScript_Sandbox where applicable as I think it may help minimize the freezes further (even if not fully resolve it yet).

Meanwhile, thank you for continuing to look at the issue and hopefully a permanent solution is in the horizon