skip to content

Explain the difference between mustRunAfter and shouldRunAfter, including how each behaves when honoring the rule would create a cycle.

level: middleimportance: must knowfreq 60%

answer

  1. must = hard, always honored
  2. should = best-effort, dropped on cycle
  3. should yields to real dependencies
  4. drop is silent, no error
  5. must can break the graph; should won't

basics

~20 s

mustRunAfter is a hard ordering constraint that Gradle always honors when both tasks run. shouldRunAfter is best-effort: Gradle tries to honor it but silently drops it if honoring it would create an ordering cycle (or conflict with a real dependency).

solid answer

~50 s

Both declare that one task should run after another *when both are scheduled*, but they differ in strictness: - **`mustRunAfter(other)`** — a **hard** ordering rule. When both tasks are in the graph, Gradle guarantees the order. It cannot be overridden. - **`shouldRunAfter(other)`** — a **best-effort** ordering rule. Gradle honors it normally, but **drops it** in two situations: (1) honoring it would introduce an **ordering cycle**, or (2) it conflicts with an actual task dependency (dependencies always win). No error is raised — the rule is just ignored for that build. Use `mustRunAfter` when the order is correctness-critical (e.g. a cleanup must precede a build step). Use `shouldRunAfter` when the order is merely a preference — for example, you'd *prefer* `test` ran before `integTest` for nicer failure ordering, but you don't want a hard guarantee that could ever deadlock the graph. Importantly, `mustRunAfter` can itself contribute to an unresolvable graph, whereas `shouldRunAfter` will yield rather than break.

code

kotlin · 9 lines
kotlin
tasks.register("a")
tasks.register("b") {
    dependsOn("a")          // real dependency: a -> b
    // Soft rule asks for the OPPOSITE order; it conflicts, so Gradle drops it
    shouldRunAfter("a")     // wait, this agrees; show the conflict version below
}

// Conflict example: a shouldRunAfter b, but b depends on a -> soft rule dropped
tasks.named("a") { shouldRunAfter("b") }   // silently ignored, no error

go deeper

for a junior

Know that must = hard guarantee, should = best-effort that can be dropped.

for a middle

Explain the two drop conditions for shouldRunAfter (cycle, dependency conflict) and that the drop is silent.

for a senior

Reason about when must can make a graph unresolvable vs should yielding, and pick the right one for correctness vs preference.

for a principal

Set conventions for when teams may use must (correctness) vs should (cosmetic), to avoid fragile cross-module graphs.

## Two strengths of the same idea Both `mustRunAfter` and `shouldRunAfter` add an **ordering edge** (sequence only, no forcing of execution). They differ in how strictly Gradle enforces that edge. ### `mustRunAfter` — hard ordering When both the constrained task and its target are in the graph, Gradle **always** runs them in the specified order. There is no fallback. If a set of `mustRunAfter` rules plus real dependencies cannot all be satisfied, the build can fail with an ordering/circular-reference problem — Gradle will not silently bend a `must` rule. ### `shouldRunAfter` — soft, best-effort ordering Gradle treats `shouldRunAfter` as a **preference**. It honors it when possible, but **automatically drops** the constraint if: 1. **Honoring it would create a cycle.** Suppose A `shouldRunAfter` B, but B already (transitively) depends on A. Honoring the soft rule would require A both before and after B — impossible. Gradle drops the soft rule, no error. 2. **It conflicts with a real dependency.** Dependencies (`dependsOn`, inferred output-input, `finalizedBy` ordering) take precedence; a contradicting `shouldRunAfter` is discarded. This makes `shouldRunAfter` safe to sprinkle across a build for *cosmetic* or *preferred* ordering without ever risking a broken graph. ## When to use which ```kotlin // Correctness-critical: cleanup MUST precede packaging when both run tasks.named("packageDist") { mustRunAfter("cleanStaging") } // Preference only: we'd like unit tests before integration tests, but never deadlock tasks.named("integTest") { shouldRunAfter("test") } ``` ## Decision guide | Need | Choose | |---|---| | Order is required for correctness | `mustRunAfter` | | Order is a nicety / readability of output | `shouldRunAfter` | | Want a constraint that never breaks the graph | `shouldRunAfter` | | Want a guarantee even at risk of a graph error | `mustRunAfter` | ## Gotchas - Neither rule pulls the target into the graph — both are conditional on the target already running. - `shouldRunAfter` being silently dropped means you should not *rely* on it for correctness; treat it as advisory. - Multiple `mustRunAfter` targets can be passed: `mustRunAfter("a", "b")`.

  • If a `shouldRunAfter` rule and a `dependsOn` dependency demand opposite orders, which wins?
    The dependency wins. `shouldRunAfter` is best-effort and is dropped whenever it conflicts with a real dependency; no error is raised.
  • Can `mustRunAfter` ever be silently ignored like `shouldRunAfter`?
    No. `mustRunAfter` is hard — Gradle never drops it. If it can't be satisfied alongside other constraints, the build can fail rather than silently bend the rule.
  • Do either of these rules force the target task to execute?
    No. Both only sequence tasks that are already scheduled; neither adds a task to the graph or forces it to run.

saying these in an interview costs you the question

  • Saying shouldRunAfter throws an error on a cycle (it silently drops instead).
  • Claiming mustRunAfter is best-effort or can be overridden.
  • Relying on shouldRunAfter for correctness-critical ordering.

context

resolving links…