turbo icon indicating copy to clipboard operation
turbo copied to clipboard

flag --continue=false or default value is not stopping the pipeline (new issue in ^1.5.5)

Open AddictArts opened this issue 3 years ago • 8 comments

What version of Turborepo are you using?

1.5.6

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

npm

What operating system are you using?

Windows

Describe the Bug

Turbo cli used to stop execution when a task had an error, now it doesn't in recent versions. Note, forcing --continue=false on the command line further doesn't stop turbo cli from going on.

//:outdated: ERROR: command finished with error: command (\Software\oranges) npm run outdated exited (1)

Expected Behavior

The pipelines stop and the turbo process exits.

To Reproduce

Add a lint pipeline and have another depend on it. Put a lint error in the code. Run the pipeline. Or use something like npm outdated and use an older package. Make this a dependency of your current pipeline. You'll see the outdated packages, but turbo will continue to execute.

AddictArts avatar Oct 12 '22 20:10 AddictArts

Hmm, I was not able to reproduce this. To make sure I understand, you're running some pipeline that has tasks that depend on //:outdated, //:outdated is failing, but the tasks that depend on it are continuing to run?

Note that there may be tasks that run in parallel with //:outdated that continue to produce output before turbo shuts them down.

gsoltis avatar Oct 12 '22 20:10 gsoltis

Hmm, I was not able to reproduce this. To make sure I understand, you're running some pipeline that has tasks that depend on //:outdated, //:outdated is failing, but the tasks that depend on it are continuing to run?

Note that there may be tasks that run in parallel with //:outdated that continue to produce output before turbo shuts them down.

Correct all the dependsOn tasks keep going and don't stop.

Note this even happens for lint errors as eslint spits them out. Note: a multi "dependsOn": ["//#outdated", "lint", "test", "dev"],`

In the above any failure in lint, test or //#outdated do not prevent dev from going. This issue showed up in the latest. It used to stop.

AddictArts avatar Oct 12 '22 20:10 AddictArts

In that example, "dependsOn": ["//#outdated", "lint", "test", "dev"],, an error in lint, test or //#outdated shouldn't prevent dev from starting. As written, dev doesn't depend on lint, test or //#outdated.

What should happen, if, e.g. lint, encounters an error: the lint task exits, turbo will not start any new tasks, and tasks that are already running will be stopped. Note that there is a race condition here, some tasks may complete before they can be stopped.

The final result from turbo should show run failed with some additional details and have a non-zero exit code. Are you seeing that output? Or are you seeing success reported?

Can you provide a repro similar to your setup? For a failing task, something like "scripts": { "build": "exit 2" }, should be fine.

gsoltis avatar Oct 12 '22 22:10 gsoltis

Thanks @gsoltis but dev does depend on lint, and test

    "dev": {
      "dependsOn": ["lint", "test"],

The one task that the dependsOn came from is called dev:outdated

No I am not seeing a non-zero output and no run failed.

AddictArts avatar Oct 12 '22 23:10 AddictArts

@AddictArts can you provide a sample repository demonstrating the issue, along with the turbo command you're running?

gsoltis avatar Oct 13 '22 00:10 gsoltis

@AddictArts starting from here would be fantastic:

npx create-turbo@latest
cd my-turborepo

Then create a commit that creates the repository state you're looking for, and then a commit that introduces a failing script.

Our test process will be:

  • Clone the repository.
  • Check out HEAD~1.
  • Run the build.
  • Check out HEAD.
  • Run the build.

nathanhammond avatar Oct 14 '22 06:10 nathanhammond

I also have a very similar issue in my repo. I have a build workspace that depends on the build of many other workspaces, yet if any of those other workspaces fail to build the overall turborepo process will succeed instead of failing.

blarfoon avatar Nov 04 '22 20:11 blarfoon

@killpowa can you get us a reproduction? We've attempted to investigate this and have not been able to reproduce the failure as described.

nathanhammond avatar Nov 09 '22 16:11 nathanhammond

Closing due to inactivity and stale version. If you're still running into this problem, please file a new issue.

anthonyshew avatar Dec 06 '23 04:12 anthonyshew