Comments (15)
@JavaScriptBach just my two cents as an external, I looked into this a little bit out of curiosity and it seems that the numbers not adding up is somewhat expected.
Look at this unit test that basically tests that those numbers are created correctly.
- It starts four tasks
- it simulates four possible outcomes: success, cache hit, failure and cancel
- cancelled task is not tracked
So I would assume that the tasks that are not run are cancelled for some reason, a "turbo internal reason", perhaps. In case you can reproduce this reliably, maybe looking at internal logs via --verbosity
will be interesting.
from turbo.
@JavaScriptBach could you try 1.13.4-canary.2 and see if the problem persists?
from turbo.
My issue seems to be fixed by omitting all leading ./
s for globs in the config file. These are my changes:
{
"$schema": "https://turbo.build/schema.json",
"extends": ["//"],
"pipeline": {
"build": {
- "inputs": ["./scripts/**", "./source/**", "tsconfig.*"],
+ "inputs": ["scripts/**", "source/**", "tsconfig.*"],
"outputMode": "new-only",
- "outputs": ["./dist/**"]
+ "outputs": ["dist/**"]
}
}
}
Here is the commit
That being said, it is weird that the summaries list the same files before and after this change.
I should add that the only reason I tried this is that I noticed all globs in the config are formatted like this. IMO this goes against the intuition that the docs transport when they state:
inputs
globs must be specified as relative paths rooted at the package's directory.
from turbo.
My issue is separate from @Isokaeder and @FlorianWendelborn's, which seems to be about caching. Can we move that discussion into a separate thread?
The issue that I'm running into is that Turbo sometimes runs fewer tasks than it should. It's not a question of caching; those tasks just aren't even run, and no output from them is listed.
from turbo.
@FlorianWendelborn @Isokaeder The graph you've provided shows what I'm describing. You have a misconfiguration since your ESLint configuration package is not a part of the dependency tree for the rest of the packages you want to invalidate cache for. If you'd like, please make a Discussion and the community may be able to provide some help.
@JavaScriptBach That's looking suspicious. I'm interested to see what more we can learn. A couple questions as we start looking at this:
- I see you've mentioned you're using a Yarn >1 version. Which version are you on? Note that v4 support is partial so you may have run into a bug there. (We have it marked as partial because it doesn't get much usage. We don't want to mark it as stable until we've had it battle-tested by the community - so thank you for being a part.) π
- You've mentioned you're using
[email protected]
. Can you verify that you still see this behavior on the latestcanary
?
from turbo.
Closing as original issue @JavaScriptBach brought up has been resolved.
@Isokaeder Please open a new issue for your problem if needed.
from turbo.
I just noticed a similar issue in our project.
In my case:
OS
MacOS
package manager
yarn v1
canary version
v1.13.4-canary.0
Description:
I only have our actual repo and branch where the issue occurred. It is not a minimal example by any means, but won't have time soon to come up with one.
On the branch in question a eslint-config
project is introduced. It has a turbo.json as all of our packages. It looks like this:
{
"$schema": "https://turbo.build/schema.json",
"extends": ["//"],
"pipeline": {
"build": {
"inputs": ["./scripts/**", "./source/**", "tsconfig.*"],
"outputMode": "new-only",
"outputs": ["./dist/**"]
}
}
}
However, changes to ./source/index.ts
would not cause a cache miss, the package did not build without passing a --force
flag.
After investigating this a little bit, the one noteworthy thing is that I ran yarn run turbo run build --filter=eslint-config --summarize
before and after changing the file (by commenting out notable chunks of the code). For both json files the hashes for index.ts
file are the same. That reads to me that for whatever reason turbo did not pick up on the file change.
If I can help in any way to investigate this further, I am glad to do so :-)
from turbo.
@Isokaeder Looking at the repo you've posted, it appears the @3yourmind/eslint-config
is missing in the dependency list for other packages. For instance, I don't see it here or here. Without those dependency relationships, Turborepo won't know that it should miss cache since those packages don't have any relationship with the ESLint configuration package.
There also could be a genuine bug here from the original report but there's no reproduction for us to look at there. But, as far as the repro that's linked from @Isokaeder goes, I'm not sure that we have a genuine globbing bug based on what I'm seeing so far.
Re: The docs globbing paths description @Isokaeder has quoted above
That does look to be unclear when thinking about Package Configurations and I'll give that more clarity in our upcoming docs rewrite. Thank you for mentioning that. π
from turbo.
@anthonyshew Thanks for looking into this. This package isnβt really a dependency of the other packages per se. We basically use it like this for our yarn run
/turbo run
check:eslint
task:
https://github.com/3YOURMIND/kotti/blob/1930ed35f838feecc39f880d4f22892ca40d30c3/turbo.json#L18-L23
For this task, turbo
also correctly resolves the dependencies:
$ turbo run check:eslint --graph
digraph {
compound = "true"
newrank = "true"
subgraph "root" {
"[root] @3yourmind/documentation#check:eslint" -> "[root] @3yourmind/eslint-config#build"
"[root] @3yourmind/documentation#check:eslint" -> "[root] @3yourmind/kotti-ui#build"
"[root] @3yourmind/documentation#check:eslint" -> "[root] @3yourmind/yoco#build"
"[root] @3yourmind/eslint-config#build" -> "[root] ___ROOT___"
"[root] @3yourmind/eslint-config#check:eslint" -> "[root] @3yourmind/eslint-config#build"
"[root] @3yourmind/kotti-ui#build" -> "[root] @3yourmind/kotti-ui#build:tokens"
"[root] @3yourmind/kotti-ui#build" -> "[root] @3yourmind/kotti-ui#build:vite"
"[root] @3yourmind/kotti-ui#build" -> "[root] @3yourmind/kotti-ui#build:vue-tsc"
"[root] @3yourmind/kotti-ui#build" -> "[root] @3yourmind/vue-use-tippy#build"
"[root] @3yourmind/kotti-ui#build" -> "[root] @3yourmind/yoco#build"
"[root] @3yourmind/kotti-ui#build:tokens" -> "[root] ___ROOT___"
"[root] @3yourmind/kotti-ui#build:vite" -> "[root] @3yourmind/vue-use-tippy#build"
"[root] @3yourmind/kotti-ui#build:vite" -> "[root] @3yourmind/yoco#build"
"[root] @3yourmind/kotti-ui#build:vue-tsc" -> "[root] @3yourmind/vue-use-tippy#build"
"[root] @3yourmind/kotti-ui#build:vue-tsc" -> "[root] @3yourmind/yoco#build"
"[root] @3yourmind/kotti-ui#check:eslint" -> "[root] @3yourmind/eslint-config#build"
"[root] @3yourmind/kotti-ui#check:eslint" -> "[root] @3yourmind/vue-use-tippy#build"
"[root] @3yourmind/kotti-ui#check:eslint" -> "[root] @3yourmind/yoco#build"
"[root] @3yourmind/vue-use-tippy#build" -> "[root] ___ROOT___"
"[root] @3yourmind/vue-use-tippy#check:eslint" -> "[root] @3yourmind/eslint-config#build"
"[root] @3yourmind/yoco#build" -> "[root] ___ROOT___"
"[root] @3yourmind/yoco#check:eslint" -> "[root] @3yourmind/eslint-config#build"
"[root] root#check:eslint" -> "[root] @3yourmind/eslint-config#build"
}
}
Here I am on the commit before our switch away from ./
(3YOURMIND/kotti@1930ed3):
As you can see, it did not understand that the eslint-config
changed (I added a comment at the end) and assumed itβs supposed to be cached/already on disk
Switching back to the version without ./
it works as expected:
from turbo.
@anthonyshew OK, I got a Turbo run summary from a failed run. Most of the task IDs are sensitive because they contain the names of our services, but here's a small snippet to help illustrate the problem:
sanitized.json
In it, we can see that
- I ran
turbo run typecheck find-unused lint circular --continue
, so I expect this to run thetypecheck
job in every project. server-common#typecheck
was listed in thedependents
field of several jobs that were ran.server-common#typecheck
itself was never ran. It never shows up as ataskId
in the summary.
Looking at the execution
field, I also see interesting things:
"execution": {
"command": "turbo run typecheck find-unused lint circular --continue",
"repoPath": "",
"success": 103,
"failed": 0,
"cached": 32,
"attempted": 165,
"startTime": 1715029673168,
"endTime": 1715029831790,
"exitCode": 0
},
- The
attempted
number is too little. Some tasks (e.g.server-common#typecheck
) were never attempted at all, when they should have been. success + failed + cached
adds up to less thanattempted
. This also looks wrong; I'd expect these numbers to add up? Looking at the output, I see this:
server-common:lint
cache miss, executing 8140116d8569dc58
Tasks: 135 successful, 165 total
Cached: 32 cached, 165 total
Time: 2m38.622s
However, server-common#lint
was also not one of the tasks run in the summary.
To summarize, it seems like there are 2 issues:
- Turbo is not finding all the tasks to run (e.g.
server-common#typecheck
). This results in it reporting an incorrect number forattempted
. - Turbo claims to run some tasks, but exits successfully before running them (e.g.
server-common#lint
). This results insuccess + failed + cached
being less thanattempted
.
Let me know 1) if you agree that this is a bug in Turbo and 2) if more information would help to triage and fix this.
from turbo.
Re-opening, closed by accident.
from turbo.
I got a debug log of a failure and I see these lines at the end, suggesting that Turbo is interrupting jobs instead of waiting for them to finish:
2024-05-07T22:12:12.966+0000 [DEBUG] turborepo_lib::process::child: waiting for child 12207
2024-05-07T22:12:12.967+0000 [DEBUG] turborepo_lib::process::child: stopping child process
2024-05-07T22:12:12.967+0000 [DEBUG] turborepo_lib::process::child: starting shutdown
2024-05-07T22:12:12.967+0000 [DEBUG] turborepo_lib::process::child: sending SIGINT to child 10417
2024-05-07T22:12:12.967+0000 [DEBUG] turborepo_lib::process::child: waiting for child 10417
2024-05-07T22:12:12.967+0000 [DEBUG] turborepo_lib::process::child: stopping child process
2024-05-07T22:12:12.967+0000 [DEBUG] turborepo_lib::process::child: starting shutdown
2024-05-07T22:12:12.967+0000 [DEBUG] turborepo_lib::process::child: sending SIGINT to child 11262
2024-05-07T22:12:12.967+0000 [DEBUG] turborepo_lib::process::child: stopping child process
2024-05-07T22:12:12.967+0000 [DEBUG] turborepo_lib::process::child: starting shutdown
2024-05-07T22:12:12.967+0000 [DEBUG] turborepo_lib::process::child: sending SIGINT to child 11817
2024-05-07T22:12:12.967+0000 [DEBUG] turborepo_lib::process::child: waiting for child 11817
2024-05-07T22:12:12.967+0000 [DEBUG] turborepo_lib::process::child: stopping child process
2024-05-07T22:12:12.967+0000 [DEBUG] turborepo_lib::process::child: starting shutdown
Under what circumstances is Turbo expected to do this?
from turbo.
@anthonyshew I'm using Yarn 4.2.1. I'll work on getting a repro in canary.
edit: I was able to reproduce this issue in Turbo 1.13.3, though.
from turbo.
Thanks @chris-olszewski. I installed this on my CI, and a small percentage of the time, I now get:
x internal errors encountered: external process killed a task
Followed by Turbo exiting unsuccessfully.
from turbo.
Okay, this indicates that something outside of turbo
sent a kill signal to one of the child processes. Previously, I've seen this when there's some OOM killer on a machine that kills processes that use up too much resources.
I'm sorry I can't offer much more help for debugging, but we don't get any information from the process exit status about what killed it.
from turbo.
Related Issues (20)
- 'INCLUDE_VUE' ...Finishing writing to cache... Oops! Turbo has crashed. HOT 1
- StyledComponents config should allow empty topLevelImportPaths & meaninglessFileNames array HOT 2
- svg with fragment not support HOT 4
- Development not running in interactive mode HOT 2
- Keypress interaction with `vite` doesn't work ("o"+Enter doesn't open web) HOT 2
- Support pnpm.ignoreOptionalDependencies when pruning lockfile
- turbo 2.0.10 prints turbo version to stderr breaking CI pipeline HOT 4
- create-turbo not working HOT 2
- Docs: Registering Root Tasks - Incorrect/Unclear example
- Misleading example in multi-language support docs
- Yarn 4: Respect `enableTransparentWorkspaces: false` when resolving workspace dependencies HOT 1
- Turbo `v2.0.10-canary.1` and newer - port forwarding stopped working (`v2.0.10-canary.0` and older is fine) HOT 1
- Docs: Add any recommendations on how to manage cache using Just-In-Time packages. HOT 1
- Issue while reading "/home/user/repo/.npmrc". Failed to replace env in config: ${NODE_AUTH_TOKEN} HOT 1
- [Linux] `turbo watch *` very often results in `discovery failed: bad grpc code`/`channel closed` error messages HOT 1
- Docs: Docs is down, just returns a 404 HOT 1
- npx create-turbo@latest - strange error starting from scratch HOT 1
- Turbo crashes HOT 7
- Γ invalid turbo json Error: Γ No "extends" key found if `./` is specified in the pnpm-workspace packages HOT 1
- breaking change from tui-term used in turborepo-vt100 breaks the building procedure when turborepo-lib used as a git dependency HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from turbo.