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

[Bug]: Execution context was destroyed, most likely because of a navigation on component mount #34495

Open
pbrzosko opened this issue Jan 27, 2025 · 5 comments

Comments

@pbrzosko
Copy link

Version

1.49.1

Steps to reproduce

Unfortunately I am not able to prepare a minimal reproduction repository, as I doesn't happen there.

But on our CI pipelines in the tests, which I can not share with you, we are using @playwright/experimental-ct-vue": "1.49.1 and we randomly get errors like that:

Error: Execution context was destroyed, most likely because of a navigation.
90 |
91 | async function mountComponent(mount: MountFunction, parentStepId: string) {
> 92 |   await mount(ProtocolStepCreate, {
|         ^

It is random which test fails, but it is always pointing to the mount method.
I didn't encounter this locally, so it seems to only happen on CI on Azure.

Expected behavior

We expect tests to be stable.

Actual behavior

Tests are randomly failing because of random problem happening on component mount.

Additional context

Can we extract some logs, that would help figuring out what is happening?

Environment

System:
    OS: macOS 15.2
    CPU: (10) arm64 Apple M2 Pro
    Memory: 2.22 GB / 32.00 GB
  Binaries:
    Node: 20.14.0 - /usr/local/bin/node
    npm: 10.8.3 - /usr/local/bin/npm
  Languages:
    Bash: 3.2.57 - /bin/bash
@ValereTamwo
Copy link

Hello, I just deployed my codebase on a new computer and installed all the necessary dependencies to make it run. However, I’m encountering the same issue, even though it was working perfectly in my previous setup. I’m not sure what’s going on.

@agg23
Copy link
Contributor

agg23 commented Jan 27, 2025

Can you try to find a minimal reproduction? It's very difficult to help users if we don't have a quick way of following their issue.

@GeneratorX16
Copy link
Contributor

This usually happens when the server is not ready and does a reload to optimize the dependencies, leading to the destruction of execution context. I experienced it on dev server using vite, but on retry it works, since the vite server has already optimised the dependencies after the first failed mount.

Do you experience this in the build mode or by running the dev server ?

@pbrzosko
Copy link
Author

It is only happening on CI for me so in build mode. We had similar issues with Cypress, where it couldn't load a dependency. I think solution there (in the Cypress ticket) was to optimize dependencies in Vite, but that didn't help there. Do you know a way to get around it or we should add retries on the CI and live with it?

@GeneratorX16
Copy link
Contributor

GeneratorX16 commented Jan 31, 2025

In my case, since I knew this issue would only popup once before the test suite, I handled this by creating a global-setup test, in which I would mount the component having all the dependencies and check for the "Execution Context" error to be thrown. If the error was thrown, it meant I would never see this error in any subsequent test since the server has reloaded once and would never do it again, so the other tests would run fine.

Then I added this test as a dependency on all other projects, so that whenever any project runs, this is the first one to run.

Another method would be to wrap the mount fixture with retries using try catch.

try {
const c = await mount(<Component />);
await expect(c).toBeVisible();
} catch(err) {
 if (err.message.includes("Execution Context was destroyed")) {
   console.log("Server has reloaded, your tests are ready to run");
return;
} else console.log("Unidentified error")
throw err
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants