-
-
Notifications
You must be signed in to change notification settings - Fork 187
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
Random Eslint failure since upgrading to v5.2.1 #671
Comments
Please provide a runnable reproduction. |
@JounQin I don't have one right now - because I can only get it to fail on our CI build. I downgraded last week & re-upgraded this week - hoping it was just random. But to no avail. But judging from the 👍 on my report - seems like I might not be the only one. 👀 |
Just a heads up that this is still an issue for us ☝️ |
The thumbs up help nothing, we need a reproduction to debug. |
We're having the same issue, running Given that @andrewbrennanfr 's stack trace appears to be erroring at https://github.com/fmal/synckit/blob/bd607595c13c133df7544bb5281fd2e29ddc52ba/src/index.ts#L547, it looks like This is happening on node v20.16.0 which might be relevant given this PR in the release un-ts/synckit#175. @andrewbrennanfr which version of node are you seeing the error in? |
Maybe you can use |
As I said, it only happens on our CI, so I don't have an example to share.
We don't use next, but we do use github actions. So somewhat similar.
Node 20.x (
This doesn't work at It's hard to know, because it's somewhat flaky to reproduce. But I can say that running the linter on github actions, with node20.11 has at least intermittent errors. |
Can confirm the same error happening in CI for us (seemlingy random):
Packages: Node 20.12.0 and yarn 4.1.1 but no pnp only regular node-modules |
Can confirm pinned |
Here the error is intermittent, sometimes it occurs in the pipeline, sometimes it doesn't. Packages:
Node: v20.16.0 Error:
|
Here's mine. Seems to only affect the CI environment:
|
Looks like the error could be in Synckit: Maybe sometimes receives messages that aren't objects with a What are those messages and where are they coming from? |
Ran into this issue today as well. Using overrides with "overrides": {
"eslint-plugin-prettier": {
"synckit": "0.8.8"
}
}, |
Hi 👋 Just an update here (as I opened this issue). In the end we've removed this plugin from our stack & gone back to using Prettier as a standalone tool. For a while we've wanted to just manage the code formatting ourselves with Prettier. And after hitting this issue - it pushed us to just go back to using Prettier instead. So I'll leave the issue open for others who face the problem. But on our side it's no longer a problem. 🙂 Thanks 👍 |
From the error call stack, this is the line that is failing: https://github.com/un-ts/synckit/blob/42918e8b340b7b6466a5ba280b946b78735877b3/src/index.ts#L547 where receiveMessageOnPort is a node function that may return Therefore @JounQin it would be prudent to have a - const { id, ...message } = (receiveMessageOnPort(mainPort) as { message: WorkerToMainMessage<R> }).message
+ const received = receiveMessageOnPort(mainPort) as { undefined | message?: WorkerToMainMessage<R> };
+ if (!received) {
+ // TODO: Handle undefined
+ } else {
+ // happy path
+ const { id, ...message } = received.message; as well as maybe assess when this function could be called out of turn? However, I see a PR has been merged 4 days ago pertaining to this code: un-ts/synckit#184 @JounQin could you comment if this could impact/help resolve this issue based on the stack trace? Perhaps @jedlikowski could help here also? One last thing around pinning 0.8.8:
If 0.9.0 fails and 0.8.8 is succeeding, there's not too much that has changed in synckit since then: un-ts/synckit@ Looking at that diff I can't see any reason there would be a regression in those changes. |
If we can not determine which change impact the new random behavior, I don't think we can fix it confidentially. Mostly it could be related to un-ts/synckit#154 cc @onigoetz Any idea? |
Hey @JamesBurnside, in the mentioned PR, I worked on gracefully handling tasks that timeout in the main process but still successfully finish in the worker process. My initial idea was to create a separate MessageChannel for execution of Just adding my perspective here :) |
I can shortly confirm that it is failing with the exact stacktrace only on github actions 1 out of maybe 30 runs. It's so hard to create a reproducible case. |
What version of
eslint
are you using?8.57.0
What version of
prettier
are you using?Not installed as a dep of our project, but
npx prettier --version
returns3.2.5
What version of
eslint-plugin-prettier
are you using?5.2.1
Please paste any applicable config files that you're using (e.g.
.prettierrc
or.eslintrc
files)What source code are you linting?
.vue/.ts
What did you expect to happen?
For the linter to succeed
What actually happened?
In our the CI build, we have (seemingly random - as repeated runs causes it to pass) errors during linting.
Local runs of the linter do not fail, only in the CI.
Our error looks something similar to this (I've removed some details to make it more readable) & mentions
synckit
which was upgraded in the latest version ofeslint-plugin-prettier
.Downgrading to the previous version we had installed
5.1.3
, looks to fix the issue.The text was updated successfully, but these errors were encountered: