Skip to content

Fixes a race in FormatterStepSerializationRoundtrip.HackClone.writeObject#2994

Open
bric3 wants to merge 2 commits into
diffplug:mainfrom
bric3:hackclone-race
Open

Fixes a race in FormatterStepSerializationRoundtrip.HackClone.writeObject#2994
bric3 wants to merge 2 commits into
diffplug:mainfrom
bric3:hackclone-race

Conversation

@bric3

@bric3 bric3 commented Jul 6, 2026

Copy link
Copy Markdown
Contributor

There's a race in FormatterStepSerializationRoundtrip.HackClone.writeObject when certain conditioin are met, this PR to fixes it by publishing an object.

Previously, HackClone assigned its cleaned clone before populating the clone’s equality or roundtrip state. If another Gradle worker serialized the same clone during that window, the nested FormatterStepSerializationRoundtrip.writeObject guard could see an half-initialized cleaned and then fail.

This now builds the cleaned clone locally, initializes the requested state, and only then publishes it.

Adds a Gradle regression intgeration test that exercises the task input fingerprinting. In a real project the issue was caused by a configuration like this:

plugins {
  id("com.diffplug.spotless") version "8.4.0"
}

allprojects {
  spotless {
    groovyGradle {
        toggleOffOn() // actual FencedStep, that wraps the actual formatter
        target '**/*.gradle' // target that match no files init the project, cause early task input fingerprinting
        greclipse() // lazy formatter that happens to be slow to init
    }
  }
}

And

  • the project had no more files matching the target.
  • the Gradle parallel mode is enabled

The added integration test, mimick the issue in a more deterministic way, by using the primitives to create the steps.


After creating the PR, please add a commit that adds a bullet-point under the [Unreleased] section of CHANGES.md, plugin-gradle/CHANGES.md, and plugin-maven/CHANGES.md which includes:

  • a summary of the change
  • either
    • a link to the issue you are resolving (for small changes)
    • a link to the PR you just created (for big changes likely to have discussion)

If your change only affects a build plugin, and not the lib, then you only need to update the plugin-foo/CHANGES.md for that plugin.

If your change affects lib in an end-user-visible way (fixing a bug, updating a version) then you need to update CHANGES.md for both the lib and all build plugins. Users of a build plugin shouldn't have to refer to lib to see changes that affect them.

This makes it easier for the maintainers to quickly release your changes :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant