Update polling and timeout message handling | CTT-188

[codingLogan]

This PR implements some edge-case fixes that have been reported by customers, which cause the user to get stuck on the Connecting screen, or get the wrong screen.

1. Sometimes the first response from the backend APIs already signal that the job is done, and in an error state. The widget incorrectly would keep on polling waiting for a different response from the first one. This was recreated by using a Slow 3G network speed emulation, and using verification and No DDA member.
2. Not aggregating fix - we have a handler for when we don't have an explicit actionable error code, but we are in a connection_status that is an error. Updates were made to allow that state to be reached.
3. The two above fixes also exposed another problem. The Connecting screen is supposed to send a timeout post message after 60 seconds. Polling timing has changed in the last half-year, and this the timeout message was out of sync. This problem has also been addressed because the above two fixes changed that code as well.
4. While testing the above, it was also discovered that sometimes the widget would show a false-positive success screen in No DDA scenarios. That has also been fixed.

Fixes

• 188
• 190
• 191
• 194

Test Results

✅ Vitest
✅ New Playwright OAuth tests
✅ Cypress Tests (when npm linked to these changes)

[mwclemy]

Just for my own learning, why does verify mode need two CONNECTED updates?

[wesrisenmay-mx]

I also wonder this

[codingLogan]

This particular scenario is one reason I would like reviews from some others because it is odd. I'm open to suggestions of handling this differently. I'll find where I placed my comments about this and add them to the test file.

The gist of the problem, is that an asynchronous edge case exists... What happens behind the scenes of a member record that hits the No DDA flow, apparently is this.

1. The member goes to CONNECTED (no errors) - yay success!
2. The member then goes to IMPEDED (with errors) - oh no, error...

In some rare instances, 1 in 6, or sometimes 1 in 20 attempts, the widget would catch the CONNECTED status and show the success screen. But, it should actually be showing the IMPAIRED screen... With a second confirmed CONNECTED message we're more confident that it should actually be a success instead of an error.

[wesrisenmay-mx]

This sounds like it's a backend problem, no?

[codingLogan]

Potentially? If there is a bug, it would be with the is_being_aggregated flag. That should likely stay true until completely after the jobs are done AND NO DDA is checked for verification involved jobs.

I'll raise some questions about this behavior, but for now this is a workaround we can handle.

[mwclemy]

This sounds like a backend issue to me as well. I'm also wondering whether it's expected for a member with no DDA to be marked as CONNECTED and then IMPEDED, or if it should go straight to IMPEDED.

[wesrisenmay-mx]

This feels like a monkey patch that is adding tech debt and complexity to our widget, when the problem really should be solved on the backend. Is adding this worth it? Do we have a ticket to remove this as soon as it's fixed on the backend? Has the backend prioritized fixing this, or is this monkey patch going to delay the backend getting the proper fix in?

[codingLogan]

I'm going to leave the code in place while I personally investigate the backend behaviors. Depending on what is found we can decide to revert the monkey-patch behavior, or adjust as needed to correctly detect no dda scenarios with both polling and/or websockets.

Best scenario, is that we can figure out the complete picture back-to-front, and then move this entire set of changes forward after we apply whatever fix is necessary.