Fix flaky TestCafe OV polling test in DeviceChallengePollView_spec
#3654
Conversation
denysoblohin-okta
force-pushed
the
od-fix-flacky-poll-tests
branch
from
2bba797
to
268edc4
Compare
denysoblohin-okta
force-pushed
the
od-fix-flacky-poll-tests
branch
from
0d087d5
to
054cb76
Compare
| @@ -14,7 +14,13 @@ const request = (opts) => { | |||
| method: 'GET', | |||
| contentType: 'application/json', | |||
| }, opts); | |||
| return $.ajax(ajaxOptions); | |||
| return new Promise((resolve, reject) => { | |||
There was a problem hiding this comment.
Explain why/how this helps
There was a problem hiding this comment.
@shuowu-okta did you have a specific behavior-change related concern w.r.t. Promisifying this?
There was a problem hiding this comment.
In current code Promises are mixed with jQuery's Deferred (line 159 let probeChain = Promise.resolve(); uses Promise, $.ajax returns Deferred and done/fail APIs are used)
Tests expect that requests are performed in chain: probe port 2000 -> challenge 2000 (if probe OK) -> probe 6511 -> challenge 6511 -> probe 6512 -> challenge 6512 -> probe 6513 -> challenge 6513
With current code it's not always true, eg. probe 6511 can run in parallel with challenge 2000
So eg. this check
can fail
There was a problem hiding this comment.
Changing the base xhr approach may cause unexpected issue for legacy browsers. As the goal is to fix flaky bacon test, I propose to find another way that fix against test directly, for example, migrate test from e2e to unit level (testcafe -> jest).
There was a problem hiding this comment.
See latest commit that uses $.Deferred instead of Promise and then+catch API instead of done+fail for proper chaining.
The recommended API method to use chaining is then: https://api.jquery.com/deferred.then/
| }; | ||
|
|
||
| let probeChain = Promise.resolve(); | ||
| let probeChain = $.Deferred().resolve(); |
There was a problem hiding this comment.
will this deferred cause any degradation of UX like slower authentication speed?
There was a problem hiding this comment.
With this change the behaviour will be same as in Gen3 - probe/challenge calls will be running not in parallel, but in chain (probing/challenging for port 2 should wait for probing/challenging of port 1 to complete).
This can be slower.
But such behaviour in expected judging from code and tests.
If it's desired to have parallel requests, then tests should be rewritten to reflect this.
For example, this line should be removed:
There was a problem hiding this comment.
denysoblohin-okta
force-pushed
the
od-fix-flacky-poll-tests
branch
from
723f794
to
ffa12d6
Compare
Description:
The fix consists of 2 parts:
test.skip.requestHooks(xxx)interferes with mocks in other tests - other tests in spec can use mocks from skipped test$.ajaxin BaseOktaVerifyChallengeView - migrated from jQuery's Promise-likedone/failto nativethen/catch. With old approach,probeandchallengerequests are not chained correctly (et. probing port 6512 can be started in parallel with challenging port 6511). With native Promise it's always a chainprobe 1 -> challenge 1 -> probe 2 -> challenge 2 -> ...Notes:
testcafetaskPR Checklist
Issue:
Reviewers:
Screenshot/Video:
Downstream Monolith Build: