The initial loading state during setup process sometimes taking quite a long (sometimes > 10 seconds locally and > 20 seconds in CI)

[limonte]

There was flakiness in tests which appears to be caused by the actual slowness of the app:

The reason is that the https://www.googleapis.com/gmail/v1/users/me/settings/sendAs request sometimes takes quite a white, I personally experienced 12 seconds locally, but in CI it sometimes takes more than 20 seconds, example: https://flowcrypt.semaphoreci.com/jobs/9f63948c-b6c9-4123-8d67-236e1985c5b1

Not sure if this is something that could/should be fixed, reporting for the reference mostly.

[tomholub]

This is a mock. It's really weird for it to take that long.

[limonte]

This is a mock. It's really weird for it to take that long.

In this case, it might be something else than mock. By "locally" I meant the actual extension, not the testing environment. So, the actual https://www.googleapis.com/gmail/v1/users/me/settings/sendAs took 12 seconds once and I'm pretty sure the Internet connection was stable.

This issue might be tricky to catch because it's flaky and happens quite rarely.

[tomholub]

For the CI, are you referring to this?

✔ setup - import key - fix uids 00:56
    ℹ (attempt 1 of 1) Failed:   TimeoutError: waiting for selector `[data-test="input-compatibility-fix-expire-years"]` failed: timeout 20000ms exceeded 00:56
          at new WaitTask (/home/semaphore/git/flowcrypt-browser/node_modules/puppeteer/src/common/DOMWorld.ts:798:28) 00:56
          at DOMWorld.waitForSelectorInPage (/home/semaphore/git/flowcrypt-browser/node_modules/puppeteer/src/common/DOMWorld.ts:652:22) 00:56
          at Object.internalHandler.waitFor (/home/semaphore/git/flowcrypt-browser/node_modules/puppeteer/src/common/QueryHandler.ts:78:19) 00:56
          at DOMWorld.waitForSelector (/home/semaphore/git/flowcrypt-browser/node_modules/puppeteer/src/common/DOMWorld.ts:510:25) 00:56
          at Frame.waitForSelector (/home/semaphore/git/flowcrypt-browser/node_modules/puppeteer/src/common/FrameManager.ts:1274:47) 00:56
          at Page.waitForSelector (/home/semaphore/git/flowcrypt-browser/node_modules/puppeteer/src/common/Page.ts:3210:29) 00:56
          at ControllablePage.ControllableBase.waitAll (/home/semaphore/git/flowcrypt-browser/test/source/browser/controllable.ts:57:27) 00:56
          at Function.manualEnter (/home/semaphore/git/flowcrypt-browser/test/source/tests/page-recipe/setup-page-recipe.ts:189:28) 00:56
          at /home/semaphore/git/flowcrypt-browser/test/source/tests/setup.ts:110:7 00:56
          at /home/semaphore/git/flowcrypt-browser/test/source/test.ts:76:7 00:56
          at <async> waitAll (/test/source/browser/controllable.ts:46:19) 00:56
          at <async> manualEnter (/test/source/tests/page-recipe/setup-page-recipe.ts:87:4) 00:56
          at <async> <anonymous> (/test/source/tests/setup.ts:108:76) 00:56
          at <async> <anonymous> (../test/source/test.ts:71:53) 00:56
          at <async> <anonymous> (/test/source/browser/browser-pool.ts:143:49)

(if not, please point me to the right direction)

If yes, then these are two different issues between the CI and your local environment.

• local: it may actually be google API itself that is so slow
• the CI example above: setup - import key - fix uids is notoriously slow. I don't know what is it about that particular test, maybe it's the fixing of the openpgp key that takes so long, but really, it shouldn't. I never debugged it.

[limonte]

For the CI, are you referring to this?

Yes.

[tomholub]

Yup - that's another issue.

Gmail API may be something that we can't do much about. On the other hand, speeding up setup - import key - fix uids could be done, possibly. But I have a feeling the problem is in the extension implementation, not the test.