Tell me why a cache miss happened

[ds300]

Which project is this feature idea for?

Turborepo

Describe the feature you'd like to request

When turbo can't find a cached result, we get no information to tell us why. In the cli we only see

@scope/package:task cache miss, executing <hash>

This makes it extremely tedious to debug situations where the cache is being invalidated more often than I expect, which happens often.

I'd like a short list of the cached values that were different compared to the previous successful build.

@scope/package:task cache missed because
  changed file packages/cli/src/run.ts
  new file packages/cli/__test__/e2e.test.ts
  deleted file packages/cli/__test__/harness.ts
  changed env var NODE_ENV
  ... and 32 others. See .turbo/task.log

Describe the solution you'd like

Turbo should store a log of the most recent successful build for any given (task, package) pair. This log should include a manifest of all the input values that contribute to the composite cache key for the (task, package) pair, along with their hashes.

Whenever turbo starts a new task in a given package, it should look for the most recent log and, if found, compare the new list of input values and their hashes against the value recorded on the previous successful build.

If it finds a log and finds hash differences, it should print a concise truncated list of the differences to the cli, and a full list of the differences to the persistent task log.

Describe alternatives you've considered

I tried using the new summary.json files, but even with json-aware diffing it's quite difficult to find out what changed from one run to the next.

[tomByrer]

I guess this is your solution?
https://github.com/ds300/lazyrepo

[GiancarlosIO]

+1 it would be really helpful to understand why we get cache-miss

[jonaslindstr]

With Turbo 1.9 I have run the same small task twice, starting from an uncached state, with and without --experimental-env-mode=strict. The only differences in the JSON output are the id of the run, execution.startTime and execution.endTime on the top level and for the task itself, and then the hash of the task, tasks[0].hash.

Since the task hash is different between the runs, both runs get a cache miss. But I don't understand what the hash change is based on, since everything else in the tasks (as listed in the JSON) is the same.

[gsoltis]

@ds300 with [email protected], you should be able to use --summarize to generate a JSON file of everything turbo considered for its hash / cache calculation.

[gsoltis]

@jonaslindstr if you have a hash changing with nothing else changing in the file, can you open a new issue with the relevant details? Thanks!

[ds300]

@gsoltis --summarize exists sure, but it requires extra (as-of-yet nonexistent) tooling to be human-friendly.

This feature request is explcitly for a human-friendly way of knowing why a task reran.

[gsoltis]

@ds300 Got it. I'll leave this open as a feature request then. --summarize is new, now that we are regularly producing the data, I expect it will be a bit more tractable to layer on some tooling to get a more human-friendly view.

[NullVoxPopuli]

summarize doesn't say which of the files are different tho
(for example, I may need to hunt down where an extraneous ending newline is coming from)

[orta]

Not sure if I'll get around to a full npm package, but passing along my WIP which tells you all the inputs and logged hashes to show what changed here: https://gist.github.com/orta/f802e9389c77daab97e1194fad5a1bb0

The thing I'm finding on my runs though is that the task hash changes in something outside of those and I've not figured out what the algorithm for generating the hash is yet in a way that can be explained from just reading the summaries