axe-core: Runtime issue: Axe is already running. Use `await axe.run()` to wait for the previous run to finish before starting a new run.
<< Please describe how you encountered this issue >>
axe-core version: undefined
axe-extension version: 4.24.5
it@moz-extension://a1c77a94-b956-419f-b37e-7d85e421f84d/axe-versions/latest/axe.js:12:78706
e/</axe.run@moz-extension://a1c77a94-b956-419f-b37e-7d85e421f84d/axe-versions/latest/axe.js:12:355675
48269/<@moz-extension://a1c77a94-b956-419f-b37e-7d85e421f84d/content.bundle.js:1:21730
async*72257/h</<@moz-extension://a1c77a94-b956-419f-b37e-7d85e421f84d/content.bundle.js:61:5845
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 19 (4 by maintainers)
We see this issue ourselves when using the axe-core/react plugin on our react development environments. We’ve got this set up to only initialize in the development environment, rather than production, but still, It seems to occur in dev when our page hot reloads after a change, or something similar- I can only assume that because the process is running, it doesn’t exit gracefully. It’s been hard to nail down, as it’s intermittent- but it’s seemingly occurring in more than just jest testing runs in CI.
Screenshot of webpack’s fullscreen overlay error. Interestingly, even though this error fires, it appears the axe react tooling continues to run - almost as if it recovers after the error fires.
Well, yes and no. I ended up upgrading our monorepo piecemeal - updating the packages to the latest jest that didn’t have axe tests first, then doing them last. In the end, when I updated those final packages the problem went away. That suggested it was some sort of package dependency problem, but I don’t think so… the problem occur every now and then, even now. Just haven’t been able to identify what triggers it. Sorry. 😦
To be clear, this isn’t a parallelism issue - keeping it sequential is totally fine. When this problem occurs for us (it’s still an issue) it’s just because the previous run hadn’t been marked as “done” (pass or fail) internally within axe-core, so the next run thinks it’s being ran in parallel, which isn’t the case, and it throws this error. What I’ve been unable to figure out is why whatever is failing doesn’t get picked up by axe-core so it can mark the previous test as failed & why it’s left in an invalid state internally. I’m hoping to get more time to return to this problem soon because it’s blocked our jest upgrade.
Is there any solution for this issue when multiple tests are run concurrently? For example:
axe-core
(or a dependent likejest-axe
)@AlanSl Yeah that’s a little disappointing but makes sense! I’m working on a monorepo that’s meant to scale to include many, large projects, so I’m definitely hesitant to add an extra CI step. Your second solution seems interesting and I’ll probably give it a go. We use Chromatic as well so I might see if it’s feasible to only run a11y tests in their platform.
I am facing the same error. I am using jest-axe for testing and I got catch this error in the block when running multiple tests.
Should I update the version?
Ran into this same problem; in my case the issue was that I’d wrapped
axe.run
in an async function, but forgotten to call that function withawait
in 2+ instances, which then clashed when run together.Commenting here in case others find this through Google like I did and happened to make the same mistake.