Debugging navigationTimeout errors

[spinningarrow]

We have some recent issues where a navigationTimeout error occurs after a click or a goto. The actual navigation happens successfully well before the timeout limit. Is there a way to debug why Taiko is unable to detect the navigation? .trace doesn't really provide enough insight into what Taiko is looking for.

[spinningarrow]

Update: I tried enabling Taiko's debug log events and got wayy too much output. Are there specific events I can filter for related to why navigation is not detected?

[NivedhaSenthil]

Could be because Taiko is waiting for some network request which is not resolved, from logs you could see if there is any requestID without a matching resolved event.
yes currently it is tricky getting around the logs need to find a better way.

If it is enough to wait for the page load in your case, you could try passing waitForEvents:['loadEventFired'] as an option to goto or click so that Taiko wont wait for any request triggered along with the action.

[spinningarrow]

Thanks Nivedha! For now the problem magically solved itself by upgrading to the latest Taiko. If it comes back I’ll look into it more with your suggestions.

…

On Tue 19. Jan 2021 at 3:10 AM, Nivedha ***@***.***> wrote: Could be because Taiko is waiting for some network request which is not resolved, from logs you could see if there is any requestID without a matching resolved event. yes currently it is tricky getting around the logs need to find a better way. If it is enough to wait for the page load in your case, you could try passing waitForEvents:['loadEventFired'] as an option to goto or click so that Taiko wont wait for any request triggered along with the action. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1802 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANWZUDU7OHU3I7IL4RFGD3S2TSXPANCNFSM4WHPB57Q> .

[smv-orrin]

we have seen a similar issue that has to do with the default action of the click() api. Basically, click() api calls default to use waitForNavigation: true, which seems to be starting a countdown to a navigation event. When there is no navigation (because it's just an on-page thing, like clicking a button or other non-navigating element) it just keeps waiting until it times out, unless you're lucky and your test beats the default navigationTimeout. We got around this by passing {waitForNavigation: false} during non-navigating click() api calls.