Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Browser Test" PR Check Seems Flaky #12081

Closed
tsmaeder opened this issue Jan 17, 2023 · 1 comment · Fixed by #12117
Closed

"Browser Test" PR Check Seems Flaky #12081

tsmaeder opened this issue Jan 17, 2023 · 1 comment · Fixed by #12117
Assignees
Labels
ci issues related to CI / tests

Comments

@tsmaeder
Copy link
Contributor

The step "Browser Test" that runs as part of the CI build on Ubuntu in our PR Checks sometimes fails, sometimes it succeeds. The build job runs yarn browser test. Strangely, these tests are only run on Ubuntu, but not on Windows.

Beyond being flaky, the tests also spew out a lot of error messages, which seem unrelated to any actual failures in the tests, for example:

2023-01-13T14:29:38.875Z root ERROR Error: view container is disposed
    at ViewContainer.get containerLayout [as containerLayout] (http://127.0.0.1:3000/bundle.js:135611:15)
    at ViewContainer.getParts (http://127.0.0.1:3000/bundle.js:135595:21)
    at NavigatorTabBarDecorator.decorate (http://127.0.0.1:3000/packages_navigator_lib_browser_navigator-frontend-module_js-packages_variable-resolver_lib_br-8447b0.js:455:63)
    at TabBarDecoratorService.getDecorations (http://127.0.0.1:3000/bundle.js:126961:43)
    at TabBarRenderer.getDecorations (http://127.0.0.1:3000/bundle.js:127917:86)
    at TabBarRenderer.getDecorationData (http://127.0.0.1:3000/bundle.js:127929:21)
    at TabBarRenderer.renderIcon (http://127.0.0.1:3000/bundle.js:128041:37)
    at TabBarRenderer.renderTab (http://127.0.0.1:3000/bundle.js:127803:82)
    at SideTabBar.renderTabs (http://127.0.0.1:3000/bundle.js:128497:35)
    at SideTabBar.renderTabBar (http://127.0.0.1:3000/bundle.js:128442:18)

In the current state, the tests don't serve to catch real failures anymore, since developers will just ignore them, assuming the failures are spurious. If a developer does take the failures seriously, he will wast a lot of time to conclude that it's not a problem in the PR in many instances.

@tsmaeder
Copy link
Contributor Author

@marcdumais

@vince-fugnitto vince-fugnitto added the ci issues related to CI / tests label Jan 17, 2023
@marcdumais-work marcdumais-work self-assigned this Jan 26, 2023
marcdumais-work added a commit that referenced this issue Jan 26, 2023
Fixes #12081

Signed-off-by: Marc Dumais <[email protected]>
marcdumais-work added a commit that referenced this issue Feb 1, 2023
Opened editors referencing a deleted file have string (Deleted) after the file name.
It used to be (deleted). This commit adapts to the modified case.

Fixes #12081

Signed-off-by: Marc Dumais <[email protected]>
marcdumais-work added a commit that referenced this issue Feb 7, 2023
Opened editors referencing a deleted file have string (Deleted) after the file name.
It used to be (deleted). This commit adapts to the modified case.

Fixes #12081

Signed-off-by: Marc Dumais <[email protected]>
marcdumais-work added a commit that referenced this issue Feb 17, 2023
Opened editors referencing a deleted file have string (Deleted) after the file name.
It used to be (deleted). This commit adapts to the modified case.

Fixes #12081

Signed-off-by: Marc Dumais <[email protected]>
marcdumais-work added a commit that referenced this issue Feb 20, 2023
Opened editors referencing a deleted file have string (Deleted) after the file name.
It used to be (deleted). This commit adapts to the modified case.

Fixes #12081

Signed-off-by: Marc Dumais <[email protected]>
paul-marechal pushed a commit that referenced this issue Feb 22, 2023
* [browser tests] [launch preferences] Temporarily disable test suite

Since they consistently fail, following a recent change that uncovered a deeper bug
in the preferences.

This commit can be reverted once we have a fix for #12153

Signed-off-by: Marc Dumais <[email protected]>

* [browser tests] [saveable] - adapt to updated label

Opened editors referencing a deleted file have string (Deleted) after the file name.
It used to be (deleted). This commit adapts to the modified case.

Fixes #12081

Signed-off-by: Marc Dumais <[email protected]>

* [browser tests] [typescript] Solidify tests

Test cases 'references-view.find'/'references-view.findImplementations' is triggering a couple
of exceptions that result in error pop-ups in the app, that seem to intermittently derail the
following test cases. It happens when opening the references view directly, but not when
triggering the find references / find implementations, which in any case also
open the view.

In consequence, I have reorganized the order of operations to minimize issues: trigger
the commands first, then "open" the already opened view to get a handle on it and be able
to confirm that the content is what's expected.

Observing the failure points, added a bit more strategic "robustness" to the following TypeScript tests:
- editor.action.triggerSuggest
- Can execute code actions
- editor.action.quickFix

Also added a delay in beforeEach and afterEach handlers, to give time for code action contributions to be updated
when editors are closed and reopened. This helped with a few intermittent problems.

Signed-off-by: Marc Dumais <[email protected]>

* [browser tests] [find-replace] Solidify test

Add strategic delays to avoid a race condition that happens when files are
closed and opened in quick succession.

This test case opens and closes a '.js' file many times very quickly. The
specific file triggers the eslint and typescript-language-features plugins
to register code action handlers, that rely on the open file's to be referenced in a
structure maintained by the plugin system.

Code actions are immediately triggered upon the file being re-opened, and I think
previously registered handler do not always have enough time to be cleared, and end-up
throwing when the file can't be found in the plugin system's internal structure
(DocumentsExtImpl)

I tried but was not able to reproduce the issue manually, opening the file from
the explorer and closing it using shortcut shift-alt-w as quick as possible.

note: included a review suggestion by paul-marechal

Signed-off-by: Marc Dumais <[email protected]>

* [browser tests] [keybindings] Squash intermittent heisenbug

This one was tricky to find.

An exception would happen that failed the current test file, usually launch-preferences.spec.js,
only when running the full browser test suite. However, if that file was removed, the exception
would happen in another file, and another file...

Turns-out it's related to the vscode.json-language-features built-in extension and playing with
the package.json file.

It seems the problem is with the Language LinkProvider feature, and its usage by the
json-language-features extension. But I could not reproduce it outside of the test suite.

Here's what the exception looks-like:

root INFO   1) Launch Preferences
            "before all" hook in "Launch Preferences":
            Uncaught Error: Uncaught Error: There is no document for file:///home/<user>/theia/examples/browser/package.json

        Error: There is no document for file:///home/<user>/theia/examples/browser/package.json
            at LinkProviderAdapter.provideLinks (/home/<user>/theia/packages/plugin-ext/lib/plugin/languages/link-provider.js:31:35)
            at /home/<user>/theia/packages/plugin-ext/lib/plugin/languages.js:332:97
            at LanguagesExtImpl.withAdapter (/home/<user>/theia/packages/plugin-ext/lib/plugin/languages.js:123:20)
            at LanguagesExtImpl.$provideDocumentLinks (/home/<user>/theia/packages/plugin-ext/lib/plugin/languages.js:332:21)
            at /home/<user>/theia/packages/plugin-ext/lib/common/proxy-handler.js:91:71
            at processTicksAndRejections (node:internal/process/task_queues:96:5)
            at async RpcProtocol.handleRequest (/home/<user>/theia/packages/core/lib/common/message-rpc/rpc-protocol.js:167:28) (http://127.0.0.1:3000/vendors-node_modules_theia_monaco-editor-core_esm_vs_base_common_severity_js-node_modules_the-68fc42.js:1785)

I went with a simple fix: have the keybindings tests use an alternative file instead of package.json.

Signed-off-by: Marc Dumais <[email protected]>

* [browser tests] [browser-utils] [find-replace] increase test suites timeout

These test suites executes early, a the same time plugins are started. The default 2000ms
timeout would occasionally seemingly not be enough. Increasing it a bit.

e.g.:
2023-02-17T20:28:21.717Z root INFO   1 failing
2023-02-17T20:28:21.719Z root INFO   1) animationFrame
       should resolve after the given number of frames:
     Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.

2023-02-20T14:54:45.051Z root INFO   1 failing
2023-02-20T14:54:45.051Z root INFO   1) Find and Replace
       "after each" hook for "Replace in the active explorer with the current editor":
     Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.

Signed-off-by: Marc Dumais <[email protected]>

* [browser tests] Misc improvements in test infrastructure

Re-use puppeteer's empty Chrome tab:

Puppeteer at some point started to open the Chrome browser with an empty
tab by default. Then, when we create a new page for our tests, a new tab
would be added. At least When running the tests with UI
(option --test-inspect), sometimes the empty tab would be selected and
apparently cause many tests to fail. It's possible that this also sometimes
happened in headless mode.

To avoid this, now re-use the empty tab instead of creating a new one.

Make sure the Theia test app has focus and clear local browser storage:

When launching in non-headless mode (with a UI and dev-tools open), it looks-like
the dev-tools have focus, which interferes with some tests that query the UI,
expecting our app to be in focus. Simply clicking on the app before starting the
tests fixes it.

Also clear the local browser storage, to possibly avoid starting the app
with some state from the previous run. This could help when running the tests
locally, since CI should in theory always start with a clean environment.

Disable retry for failed tests in mocha config:

It only seems to make things worse.

Allow viewport to take available space instead of default 800x600:

This gives much more space for the Theia app, specially when running
in non-headless mode, where the editors can have very little real-estate
when views on the sides are open.

Delay exit after test finish:

When running the suite in headless mode, it exits as soon as the mocha tests
are done executing. In some cases, where there are lots of errors to report[1],
the final report did not have the chance to be printed-out, and so we were
left wondering about the details of what caused the failures.

[1]: basically the final pass/not pass/skip count as well as details about
the failed tests.

Note: includes a review suggestion by paul-marechal.

Signed-off-by: Marc Dumais <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci issues related to CI / tests
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants