Intercepting Groovy dynamic calls stops working in subsequent builds reusing a running daemon

[h0tk3y]

Current Behavior

Intercepting calls that are dynamically dispatched through Closures in Groovy build scripts works as expected in a cold daemon, but if the daemon is reused for subsequent builds, those builds do not have their dynamically dispatched calls intercepted properly.

For example, this call should always be tracked as a configuration input:

file("1.txt").with {
    println(isFile())
}

And it is in the first build, so running it will include the file system entry for 1.txt in the snapshot.
However, cleaning the configuration cache with rm -rf .gradle/configuration-cache and running the build again in the same daemon process will no longer track the isFile() call as a configuration input.

Expected Behavior

Subsequent builds in a running daemon should all intercept the Groovy calls uniformly.

Context (optional)

This is a bug in a new feature #24949.
It is most likely caused by the commit 1b36ab6.

Something in the Groovy runtime integration resets the instrumentation of the call sites for dynamic calls, and those fail to register themselves for call site matching in the intercepting meta class code.

Steps to Reproduce

Create an empty Gradle project, put the following in the build.gradle Groovy script:

file("1.txt").with {
    println(isFile())
}

Enable configuration caching in the gradle.properties:

org.gradle.configuration-cache=true

Use a Gradle Nightly distribution.
Run the build once:

gradlew help

Then clean the cache:

rm -rf .gradle/configuration-cache

And run the build again:

gradlew help

The second build will not produce a configuration report for 1.txt input, and the configuration cache entry will not be invalidated after changes to that entry (e.g. if 1.txt is created / removed).

Gradle version

8.4

Build scan URL (optional)

No response

Your Environment (optional)

No response