Fewer false cache positives: hash --only inputs and dependsOn cache=false tasks

[solsson]

• Includes all of Include outputs from dependsOn tasks in same turbo run input hashes #1
• Includes the failure expectation from Document cache behavior with --only #2 and a proposed fix

[solsson]

Research by Opus 5:

PR #3 — Fewer false cache positives: hash --only inputs and dependsOn cache=false tasks

Recommendation: partially close — split it. This PR bundles two independent fixes. Upstream has fully solved one and not started the other, so it should not be closed or rebased as a unit.

Half	Upstream status	Action
DependsOn output/input overlaps	Solved in v2.9.17–v2.10.6, opt-in	Drop from this PR — see #1
--only drops dependency edges	Untouched	Keep; this becomes the whole PR

Half 1: dependsOn overlaps — drop it

Upstream shipped structured inputs with startup / jit / dependencyOutputs modes (#13125), dependency-output hashing (#13129), and deferral cascade to dependents (#13045). Issue #8051 is closed.

Our bundle/fetch case — the motivating one, with a cache: false dependency — expresses directly. I verified against validate_dependency_outputs_inputs in v2.10.6 that the only constraint on a selected dependency is that it declares outputs; cache: false is not rejected:

{
  "tasks": {
    "fetch": { "cache": false, "outputs": ["target-fetched/**"] },
    "bundle": {
      "dependsOn": ["fetch", "^bundle"],
      "outputs": ["target/**"],
      "inputs": [
        "$TURBO_DEFAULT$",
        "!target-fetched/**",
        { "mode": "dependencyOutputs", "globs": ["target-fetched/**"], "from": ["fetch"] }
      ]
    }
  }
}

Concretely, these commits should come out of this PR:

• 8612eb1ff5 defer file hashing for tasks with dependency output inputs
• 8d09f6af36 rehash tasks whose dependencies were deferred
• 9f343fbbaa only defer when dependency task has a script
• cf9d0e2e08 / 86fcb58bd6 / 59d9f818f0 <DEFERRED> and <DEPENDS_ON_OUTPUT> dry-run display
• 64274254aa deferred → depends-on-output rename
• the turborepo-task-hash RwLock<HashMap> + update_file_hash change
• TaskHashTracker::set_hash

The RwLock one matters beyond redundancy: upstream #13273 explicitly removed locking from the hash precompute path for performance. Keeping ours would reintroduce the contention they just eliminated, and it will conflict on every rebase.

dep_output_overlap.rs (569 lines, 15 unit tests) is the exception — it has no upstream counterpart and should survive, but re-targeted. Instead of implementing deferral itself, it can emit a synthesized dependencyOutputs input at engine-build time and let upstream's machinery take over. The glob intersection it already computes is precisely what vercel#13129's coverage validation demands. That turns ~800 lines of runtime machinery into a detection pass plus an injection point.

Half 2: --only — this is the real remaining content

Upstream v2.10.6's builder.rs still silently drops these edges, identical to 2.9.10 (details in the #2 comment). Keep:

• Engine::dropped_dependencies / add_dropped_dependency and both recording sites in builder.rs
• turborepo_hash::hash_string
• the visitor fold-in of dropped-dependency SCM package hashes
• c07e27839e the warning, and 2dbb4c5987 the #[should_panic] tripwire test

Rebase note: the fold-in currently patches one call site, calculate_task_hash. Upstream now has two — calculate_task_hash and calculate_task_hash_with_deferred_inputs (visitor lines ~763–800 at v2.10.6). Both need the dropped-dependency hash folded in, or a task that uses jit/dependencyOutputs and has an edge dropped by --only will silently skip the compensation. That combination is exactly our bundle task, so it is not hypothetical. Worth a test.

The documented limitation is still there

From d57d36034e:

only works for packages that define the depended-on task. Packages without the task have no ^bundle edge to drop, so their files aren't tracked.

Upstream has not changed anything that helps here — a package with no bundle script never produces a ^bundle edge, so there is nothing to record as dropped. $TURBO_ROOT$ inputs remain the workaround. This should stay in the PR description and ideally in the warning text, since it is the case most likely to bite: a types-only package with no build step is precisely the kind of dependency people expect to be tracked.

Suggested action

1. Retitle to scope it to --only alone, e.g. "--only must not drop dependency packages from the cache key".
2. Rebase onto v2.10.6 with only the Half-2 commits, plus dep_output_overlap.rs if we pursue auto-injection — otherwise defer that to its own PR.
3. Add coverage for the deferred-inputs + --only combination noted above.
4. Fold Document cache behavior with --only #2 in here.
5. Tag the result v2.10.6-hashdepends.1. The release workflow needs its toolchain pin moved from nightly-2026-01-16 to nightly-2026-05-22 to match v2.10.6's rust-toolchain.toml; the release-turborepo profile and the cross-compilation-target step are unchanged.