Refreshing tasks fails when Gradle parallel task execution is enabled: `Resolution of the configuration 'annotationProcessor' was attempted without an exclusive lock`

[pankalog]

Extension Name: vscode-gradle
Extension Version: 3.17.2025111402
OS Version: MacOS Sequoia 15.4.1
VSCode version: 1.107.0 - commit 618725e67565b290ba4da6fe2d29f8fa1d4e3622
Gradle version: 9.2.1
JVM: openjdk 21.0.2 2024-01-16

Describe the bug
Refreshing tasks or loading the Gradle project fails when parallel task execution is enabled. It fails with:

* Exception is:
org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$IllegalResolutionException: 
Resolution of the configuration ':agent:annotationProcessor' was attempted without an exclusive lock. This is unsafe and not allowed.

But everything works properly with org.gradle.parallel=false. This isn't a solution for us, as Gradle actions take 5-6x longer.

To Reproduce
Checkout openremote/openremote@2028277 and open with DevContainer (or any VSCode IDE with Java 24 and Gradle setup).

The devcontainer has been configured correctly. Relevant gradle commands for setup are ./gradlew clean installDist and ./gradlew runDemo to run the demo.

Expected behavior
The full project is scanned and all tasks are imported.

Screenshots
If applicable, add screenshots to help explain your problem.

Output from "Gradle for Java"
You can find this by clicking on the "Output" panel, then selecting the "Gradle for Java" channel from the dropdown.

<Entire log file/stack trace attached>

gradleLogs.txt

Does the bug still exist if you disable all other extensions?
Yes

Additional context
This issue has been encountered before, and has been reported in this issue #1712 , but it seems that the issue isn't getting reopened. We cannot stop using parallelized Gradle task executions because it sharply increases our build/pipeline times, hence significantly slowing down development.

From what I understand, this can't be fixed from our end, meaning that we cannot do anything to skip that error.

Let me know if I can help in any other way. Thanks!

[github-actions]

Hi @pankalog, I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.

Workarounds & Suggestions

• Disable parallel resolution (only confirmed workaround):

  • Add to gradle.properties:

    org.gradle.parallel=false

  • Gradle docs: https://docs.gradle.org/9.0.0/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors

• Inspect cross‐project configuration resolutions in your build scripts/tasks (per comment in "Refreshing tasks" fails with "Resolution of the configuration was attempted without an exclusive lock" #1712):

  • Check if any task:
    1. Resolves a configuration in another project during its action
    2. Declares an input file collection from another project’s configuration
    3. Resolves a configuration in another project during script evaluation
    4. Resolves configurations in settings.gradle
  • "Refreshing tasks" fails with "Resolution of the configuration was attempted without an exclusive lock" #1712 (comment)

Duplicate Issue

• "Refreshing tasks" fails with "Resolution of the configuration was attempted without an exclusive lock" #1712

Other references with low confidence

• init.gradle exist one error since gradle 9.0.0 eclipse-jdtls/eclipse.jdt.ls#3505 – similar “exclusive lock” errors in an init.gradle script since Gradle 9.0.0 (but in JDT-LS, not vscode-gradle): init.gradle exist one error since gradle 9.0.0 eclipse-jdtls/eclipse.jdt.ls#3505

The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!

[pankalog]

I have already followed what the previous issue said and nothing like that is being done. Apparently, this is something that is happening outside of my project, as other commenters of the previous issue have said.