skip to content

Explain the --configuration-cache-problems=fail|warn flag (and the org.gradle.configuration-cache.problems property). When would you choose warn versus fail?

level: middleimportance: must knowfreq 50%

answer

  1. fail is the default
  2. warn = report but continue (migration)
  3. org.gradle.configuration-cache.problems property
  4. max-problems cap still applies (default 512)
  5. fail in CI to catch regressions

basics

~20 s

It controls what Gradle does when configuration-cache problems are found. fail (the default) fails the build after reporting them; warn reports them but lets the build continue. Use warn during migration to keep working, fail once you're clean to prevent regressions.

solid answer

~40 s

`--configuration-cache-problems` sets the *problems mode*: `fail` makes Gradle report all problems and then fail the build; `warn` makes it report them but continue. The equivalent property is `org.gradle.configuration-cache.problems=fail|warn` in `gradle.properties`. The default is `fail`. You pick `warn` while **migrating** a build to the configuration cache — it lets you incrementally fix problems without being blocked, and lets the build still produce artifacts (Gradle may fall back / store a degraded entry). You switch to `fail` once the build is clean so that any newly introduced problem (e.g. a plugin upgrade reintroducing a bad pattern) breaks CI immediately rather than silently degrading cache reuse. Note there's also a separate max-problems limit; even in `warn` mode exceeding it can stop the build.

code

toml · 6 lines
toml
# gradle.properties
org.gradle.configuration-cache=true
# during migration: keep building while you fix problems
org.gradle.configuration-cache.problems=warn
# optional safety cap (default 512)
org.gradle.configuration-cache.max-problems=200

go deeper

for a junior

Know fail is the default and warn lets the build continue while reporting problems.

for a middle

Explain both the CLI flag and the gradle.properties form, the default, and the warn-for-migration / fail-for-clean tradeoff.

for a senior

Bring in the max-problems cap, the degraded-entry nuance, and per-environment policy (warn locally, fail in CI).

for a principal

Define org-wide policy: enforce fail in CI, track problem counts, decide when a migration is 'done enough' to flip the gate.

## The setting When the configuration cache is enabled, Gradle's behavior on encountering problems is governed by the **problems mode**, set via: - CLI: `--configuration-cache-problems=fail` or `--configuration-cache-problems=warn` - Property: `org.gradle.configuration-cache.problems=fail|warn` in `gradle.properties` The **default is `fail`**. ## fail vs warn - **`fail`** — Gradle collects all problems, writes the HTML report, prints the summary, and then **fails the build**. This is the safe default: a build that isn't configuration-cache-clean shouldn't silently pretend to be. - **`warn`** — Gradle collects and reports the problems but **lets the build continue**. The configuration cache may still be written (sometimes as a degraded entry) and reused with caveats. This is the migration mode: you can run real builds while you work through the report. ## The max-problems interaction There is a separate cap, `org.gradle.configuration-cache.max-problems` (default 512). Even in `warn` mode, if the number of problems exceeds this cap Gradle will stop. So `warn` isn't unlimited tolerance — it's “don't fail on the first batch, but still bounded.” ## Choosing - **Choose `warn`** when you're actively migrating: you want each `./gradlew` invocation to surface the current problem set without blocking developers, so you can chip away at the report. - **Choose `fail`** (or just keep the default) once the build is clean. Now any regression — a new task, a dependency bump that reintroduces `Task.project` access at execution time, a plugin that reads a system property at config time — fails fast in CI, which is exactly what you want to keep the cache trustworthy. ## Practical pattern Many teams gate it per environment: developers may run `warn` locally during a migration sprint, while CI runs `fail` to enforce the clean state. The mode is orthogonal to *enabling* the cache (`org.gradle.configuration-cache=true`) — you can enable the cache and still choose how strict to be about its problems.

  • Does warn mode mean the configuration cache result is fully trustworthy?
    No. warn lets the build proceed and may store a degraded entry, but the reported problems indicate places where cached configuration may be stale or incorrect across runs. It's a migration aid, not a clean state.
  • If I set warn but still see the build stop, why?
    Likely you exceeded org.gradle.configuration-cache.max-problems (default 512). The cap applies independently of the fail/warn mode.
  • What's the relationship between this flag and enabling the cache?
    They're orthogonal: org.gradle.configuration-cache=true turns the cache on; the problems mode only decides how strictly Gradle reacts to problems once it's on.

saying these in an interview costs you the question

  • Saying warn disables the configuration cache — it doesn't; it just changes the reaction to problems.
  • Claiming the default is warn — the default is fail.
  • Forgetting the separate max-problems cap that can stop even a warn build.

context

resolving links…