Gradle 9.7 combined with IntelliJ IDEA 2026.2 introduces resilient sync, replacing the old all-or-nothing sync behavior. Previously, a single broken build script anywhere in a multi-project build would black out IDE support (autocomplete, highlighting) for every subproject. Now Gradle uses a new Tooling API call, BuildController.fetch(...), introduced in Gradle 9.3, to return partial models plus structured failures instead of throwing and discarding everything. As of 9.7, the sync operation is honestly marked as failed when any part breaks, while still streaming every partial model that succeeded to the IDE. This means developers can now fix build logic with IDE assistance still active, rather than losing all tooling support when a script breaks. Getting the feature requires upgrading both Gradle to 9.7+ and IntelliJ IDEA to 2026.2+; other Tooling API-based IDEs like Eclipse, NetBeans, and VS Code's Gradle tooling could adopt the same capability since it lives in Gradle itself.

7m read timeFrom blog.gradle.org
Post cover image
Table of contents
Table of ContentsIntroductionWhat goes wrong today #What is resilient sync? #A brief and slightly nerdy aside on how sync works #The part that actually shipped in 9.7 #Someone noticed #How to get it #TLDR #Discuss

Questions this post answers

What is resilient sync in Gradle 9.7 and how does it change IDE behavior when a build script fails?

Resilient sync, shipped in Gradle 9.7 alongside IntelliJ IDEA 2026.2, makes Gradle return partial tooling models for everything that configured successfully, with the rest reported as structured failures instead of aborting the whole sync. Previously, one broken script in a multi-project build would black out IDE code completion and highlighting for every subproject; now the healthy ones keep working while the sync is still honestly marked failed overall. See daily.dev for practical breakdowns of build-tool releases like Gradle 9.7 before you upgrade.

What Tooling API method enables Gradle's resilient sync feature and when was it added?

Resilient sync relies on BuildController.fetch(...), a Tooling API call added in Gradle 9.3.0. Unlike the classic getModel(...) and findModel(...) calls that throw and discard all collected data on any failure, fetch(...) returns the model it managed to build plus any encountered failures, letting the build action keep going and collect partial results as ordinary values rather than exceptions. Developers tracking Gradle internals like the Tooling API can follow these changes on daily.dev.

Do I need to enable a flag to get resilient sync working with Gradle and IntelliJ?

No opt-in flag is required; calling fetch(...) is what enables the resilient behavior, and the IDE handles that call automatically. You only need Gradle 9.7 or later (upgrade via ./gradlew wrapper --gradle-version 9.7) and IntelliJ IDEA 2026.2 or later, since both sides of the sync need to be recent for the feature to activate. Keeping toolchains like Gradle and IntelliJ current is easier when tracked on daily.dev.

8.7K Impressions