Inconsistent spying for read/navigate stages

[WesGrey]

I'm following a best practice of inserting a smart wait for an HTML mode element prior to reading/navigating it. This is very reliable, and my attributes are as refined as possible. After successfully clearing the wait stage, I can rarely receive an error in the Read or Navigate during runtime, such as: "Failed To perform Step 1 In Read Stage '' on page '' - Unable to match any windows with the query terms" Suppose my process loops through this stage for 1000 records, my bot can handle this successfully during iterations 1-600, encounter this error on iteration 601, and be successful from 602-1000. The strange thing is that I can process record 601 in the exact same way during a subsequent run, and it will be successful without hitting this error. Nothing's really too complex about the process, only one window of the target application is ever open at a time, and the element is fairly unique. I can put in retry logic for when it fails, and this generally resolves the problem. But my client would like to know why this happens for the purpose of having to deploy subsequent releases to production because of this issue. Can I get an explanation for why this element would pass the wait stage, but that same element (although rarely) fails the navigate or read stage that comes immediately after? 

[John__Carter]

The message is BP telling you that nothing in the application model matches your element. But it does seem odd if the Wait has told you that it has found a match and then in the milliseconds it takes to get to the next stage, BP complains that it can't find a match anymore. This might ultimately be one to raise with Support, but basic questions to start with would be - - Is the target app doing anything at that time, could it be still loading/refreshing/whatever, and could BP be telling the truth, ie a matching element genuinely isn't there? - Is it always on case 601? Does that case have anything odd about it? If you move that case to position 101 will it fail? Or will the issue occur on any case in 601st position? - Is the wait stage using 'Check Exists' or 'Document loaded'?

[AndreyKudinov]

There is no gaurantee that element won't disappear same second your wait returned. It might be that wait is sometimes fast enough to run and return before page started reloading (especially if there is ajax stuff going on), then read and navigate hit the moment it has not reloaded yet. If the process part is atomic, I try to wrap it in ""catch all - report - retry"" even if I never seen it fail before. Everything might work perfect, then one day web server crashes and restarts - better be ready just in case, rather than discovering in a while that your process terminated suddenly.

[AmiBarrett]

Are each of these records on the same page, or is it having to navigate to reach each one? I once ran into a page where the pathing would change based on a seed generated at the time of logging into the system. We also found that the page was dynamically generating names and ids for elements in a fairly inconsistent fashion. I'm wondering if perhaps there is some sort of dynamic page-loading interfering with the spied element(s). Although if they're all on the same page, this theory goes out the window. 😛