Vite application stopped immediately after start with `turbo >= 1.12.0`

ihmpavel commented 8 months ago

Verify canary release

[X] I verified that the issue exists in the latest Turborepo canary release.

What package manager are you using / does the bug impact?

Yarn v1

What operating system are you using?

Mac (Apple M1 Pro, 14.2.1)

Which canary version will you have in your reproduction?

1.12.3-canary.0

Describe the Bug

Our applications use Vite with config

server: {
  port: 3000,
  strictPort: true,
},

Everything was working fine, until we upgraded from turbo@1.11.x to turbo@1.12.x

After starting the application, console starts successfully, but loading localhost:3040 or current local IP shows in browser ERR_CONNECTION_REFUSED.

It looks like the application is stopped immediately, after the startup

$ yarn start --filter=@acme/app

@acme/app:start:   VITE v5.0.12  ready in 469 ms
@acme/app:start: 
@acme/app:start:   ➜  Local:   http://localhost:3000/
@acme/app:start:   ➜  press h + enter to show help

 Tasks:    1 successful, 1 total
Cached:    0 cached, 1 total
  Time:    920ms 

✨  Done in 1.75s.

Expected Behavior

I can confirm, that running yarn start in the corresponding folder without turbo starts the application and shows the same console output. Only difference is, that the console/port is still running and not closed immediatelly.

To Reproduce

1) Create MVP Vite app 2) Start with turbo in root 3) Load the URL -> it looks like the app is closed immediately

Additional context

Reverting back to v1.11.3 is working without issue. Tried all v1.12.x versions, but does not work on any.

Edit:

Looks like duplicate of https://github.com/vercel/turbo/issues/7181
Issue was introduced https://github.com/vercel/turbo/compare/v1.11.4-canary.2...v1.11.4-canary.3
Adding persistent: true fixes the problem, but it is not consistent - look at https://github.com/vercel/turbo/issues/7279#issuecomment-1931212250

ihmpavel commented 8 months ago

I tried canary releases of 1.11.4-canary.X

Everything is working fine on 1.11.4-canary.2 Does not work on 1.11.4-canary.3 - command closed immediately after starting

https://github.com/vercel/turbo/compare/v1.11.4-canary.2...v1.11.4-canary.3

e965 commented 8 months ago

I confirm the problem, encountered the same situation when upgrading turbo to the latest version

chris-olszewski commented 8 months ago

@ihmpavel Can you confirm that the task you're running is marked with "persistent": true in your turbo.json?

ihmpavel commented 8 months ago

@chris-olszewski I can confirm, that after adding "persistent": true to turbo.json the Vite application is working without an issue.

{
  "$schema": "https://turborepo.org/schema.json",
  "pipeline": {
    "start": {
      "cache": false,
+     "persistent": true
    },
    ...

What is interesting, and I did not spot that until creating this issue is, that we do some magic with Docker. Without persistent the Docker container prevented turbo to close processes (but the Vite applications were closed). That means our Docker backend was accessible on localhost, but Vite frontends were not. (Command to start everything was just $ turbo start

I am still not sure, whether it is a bug or not, because of the different behavior of Docker and I suppose of the breaking change between 1.11.x and 1.12.x?

chris-olszewski commented 8 months ago

Without persistent the Docker container prevented turbo to close processes (but the Vite applications were closed)

I'm not sure I'm following what's happening. Did you have two start tasks, one which started the backend and one which started the frontend, but the frontend wasn't starting?

Fish1 commented 8 months ago

I was running two projects at the same time, a vite and a golang server. Adding "persistent" fixed it for me.

One difference is that I never saw that my vite server ended, so I wasn't sure why I couldn't connect to my frontend.

wlcharlie commented 8 months ago

Just encountered the issue with version 1.12.3. It can be fixed by adding the persistent: true in turbo.json

ihmpavel commented 8 months ago

@chris-olszewski My behavior with Docker was identical with behavior described by @Fish1

chris-olszewski commented 8 months ago

@Fish1 So the yampms:dev task is exiting prematurely even with persistent: true?

Fish1 commented 8 months ago

@Fish1 So the yampms:dev task is exiting prematurely even with persistent: true?

Adding persistent: true fixed the issue for me.

That image is of before adding persistent true. It didn't print out that my vite server ended. It just continued like everything was working fine.

chris-olszewski commented 8 months ago

This is due to vite not printing anything when it exits due to stdin being closed. e.g. vite Hard to tell from the recording, but I'm pressing ^D to send a EOT which only results in the > appearing as my prompt.

chris-olszewski commented 8 months ago

Closing this as it can be solved with adding "persistent": true to the tasks that use the vite server. If vite is still unexpectedly closing after the addition to turbo.json, then please reopen the issue. If you encounter another tool that is stopping unexpectedly even with "persistent": true, then please open a new issue.

ihmpavel commented 8 months ago

After closing running apps (backend + vite) with persistent: true on the latest version of turbo, my terminal spits out:

@acme/backend: Gracefully stopping... (press Ctrl+C again to force) <--- our backend is handled correctly

user %  ERROR  run failed: command  exited (1) <--- this is from Vite, turbo 1.11.x did not throw this error

Does somebody has the same issue?

Full log (only Vite):

$ yarn start --filter=@acme/app
yarn run v1.22.21
$ turbo run start --filter=@acme/app
• Packages in scope: @acme/app
• Running start in 1 packages
• Remote caching enabled
@acme/app:start: cache bypass, force executing d3985bdbaf8ebfd3
$ vite

@acme/app:start:   VITE v5.1.0  ready in 393 ms
@acme/app:start:
@acme/app:start:   ➜  Local:   http://localhost:3000/
@acme/app:start:   ➜  press h + enter to show help
^C    ...Finishing writing to cache...

user %  ERROR  run failed: command  exited (1)

Dragomir-Ivanov commented 5 months ago

@ihmpavel I am experiencing the same thing. Did you managed to resolve this? Also turbo executable stays as a running in the background.

^C    ...Finishing writing to cache...

user %  ERROR  run failed: command  exited (1)

ihmpavel commented 5 months ago

@Dragomir-Ivanov Because of ERROR run failed: command exited (1) we did not upgrade turbo and we are locked on version "turbo": "~1.11.3".

@chris-olszewski Should I file new issue for this?

gaetansenn commented 1 month ago

I'm facing an issue where I have a task that uses dependsOn because my package (which I filter) depends on other packages inside the monorepo. However, when I set "persistent": true, I encounter the following error:

Error: × "@test-api/vue#dev" is a persistent task, "vue-example#dev" cannot depend on it ╭─[turbo.json:4:1] 4 │ "dev": { 5 │ "dependsOn": ["^dev"], · ───┬── · ╰── persistent task 6 │ "cache": false, ╰──── Error: × "@test-api/core#dev" is a persistent task, "@vue-api/vue#dev" cannot depend on it ╭─[turbo.json:4:1] 4 │ "dev": { 5 │ "dependsOn": ["^dev"], · ───┬── · ╰── persistent task 6 │ "cache": false, ╰────

Anyone know how to handle this situation without downgrading turbo to v1 ?

Thank you

leo-petrucci commented 1 month ago

I'm facing an issue where I have a task that uses dependsOn because my package (which I filter) depends on other packages inside the monorepo. However, when I set "persistent": true, I encounter the following error:

Error: × "@test-api/vue#dev" is a persistent task, "vue-example#dev" cannot depend on it ╭─[turbo.json:4:1] 4 │ "dev": { 5 │ "dependsOn": ["^dev"], · ───┬── · ╰── persistent task 6 │ "cache": false, ╰──── Error: × "@test-api/core#dev" is a persistent task, "@vue-api/vue#dev" cannot depend on it ╭─[turbo.json:4:1] 4 │ "dev": { 5 │ "dependsOn": ["^dev"], · ───┬── · ╰── persistent task 6 │ "cache": false, ╰────

Anyone know how to handle this situation without downgrading turbo to v1 ?

Thank you

Also having this issue, feeling like a dummy for upgrading now :/

vercel / turborepo