skip to content

What does org.gradle.configuration-cache.problems=warn do, and when would you choose it over the default?

level: middleimportance: must knowfreq 50%

answer

  1. default = fail
  2. warn downgrades problems to warnings
  3. --configuration-cache-problems=warn flag
  4. transitional / migration setting
  5. drive problems to zero, then flip back to fail

basics

~10 s

By default configuration-cache problems fail the build; setting org.gradle.configuration-cache.problems=warn downgrades them to warnings so the build proceeds. It's a transitional setting used while migrating an incompatible build.

solid answer

~40 s

When the configuration cache is on, Gradle reports any **incompatibilities** it finds — code that reads disallowed state at configuration time or holds non-serializable references. By default (`fail`) these *problems* make the build fail. Setting `org.gradle.configuration-cache.problems=warn` (or `--configuration-cache-problems=warn`) **downgrades them to warnings**, so the build completes and still stores/reuses an entry despite the problems. You use `warn` as a **transitional measure** while migrating a large build: it lets the team keep building and reaping partial benefit while incrementally fixing the reported issues. It is not a destination — leaving it on `warn` permanently means you ship builds that may silently misbehave or fail to reuse correctly, so you flip back to the default once the problem count reaches zero.

code

toml · 5 lines
toml
# gradle.properties
org.gradle.configuration-cache=true
org.gradle.configuration-cache.problems=warn
# optional: how many problems to collect before stopping
org.gradle.configuration-cache.max-problems=512

go deeper

for a junior

Know that problems fail the build by default and that =warn turns them into warnings.

for a middle

Explain it as a transitional migration aid, give the flag form, and state that the default is fail.

for a senior

Explain why a build with unresolved problems is risky under the cache and how to drive problems to zero before reverting to fail.

for a principal

Frame it as migration governance: track problem counts per build, gate the flip back to fail, and coordinate fixes across owned modules and third-party plugins.

## What a 'problem' is The configuration cache requires the configuration phase to be **deterministic and serializable**: tasks may not read live build state (like `Task.project`) at execution time, and everything captured in the task graph must be storable. Violations are reported as **configuration cache problems**. ## The three modes The behavior on encountering a problem is controlled by `org.gradle.configuration-cache.problems` (property) or `--configuration-cache-problems` (flag): - **`fail` (default):** the build fails once problems are found (Gradle still collects and reports a bounded number of them first). - **`warn`:** problems are logged as warnings, the build proceeds, and an entry is still stored/reused. ``` # gradle.properties org.gradle.configuration-cache=true org.gradle.configuration-cache.problems=warn ``` or per run: ```bash ./gradlew build --configuration-cache --configuration-cache-problems=warn ``` ## When to choose warn - **Migration:** you just turned the cache on for a big legacy build and there are dozens of problems. `warn` lets the team keep working and parallelize fixing them. - **Third-party plugins:** a plugin you cannot fix yet emits problems; `warn` keeps you unblocked until the plugin ships a compatible release. ## Why it is temporary A build with unresolved problems can behave incorrectly under the cache (stale values, missed inputs). `warn` hides the *failure* but not the *risk*. The goal is to drive problems to zero and return to `fail` so regressions are caught immediately. ## Related knobs Gradle also bounds how many problems it reports via `org.gradle.configuration-cache.max-problems` (default 512); raising or lowering it changes how much it collects before stopping, independent of fail/warn.

  • Is 'warn' a safe permanent setting?
    No. It hides the build failure but not the underlying risk — a build with unresolved problems can produce stale or incorrect results under the cache. It is meant for migration; you should fix the problems and return to the default 'fail'.
  • What is the default value of org.gradle.configuration-cache.problems?
    fail — problems cause the build to fail once detected.
  • How can you change the same setting for a single invocation without editing gradle.properties?
    Pass the command-line flag --configuration-cache-problems=warn (or =fail) on that run.

saying these in an interview costs you the question

  • Saying the default is 'warn' — it is 'fail'.
  • Recommending 'warn' as a permanent production setting.
  • Confusing problems=warn (severity of config-cache incompatibilities) with logging --warning-mode.

context

resolving links…