Corrupt serialized resolution result/Problems reading from Binary store when executing dependencies tasks or build scans
#14220
Comments
|
This morning, I actually removed that internal project, I'm still zeroing in on what triggers this. I think it may be a platform dependency in a custom source set. |
|
I've only ironed out that it only occurs when the |
|
Today I went through, and eventually figured out there were three transitive dependencies that had to be declared as It makes no sense otherwise that these dependencies would have caused any particular harm: I'll also note: we are using an internal artifactory server to both cache maven central deps (and where we host internal projects). I'm not seeing anything weird with it, so I really am not sure if it's somehow also causing issues. |
|
Thanks for the report and attempts at reproducing. These issues are usually caused by corner cases in the dependency graph computation. That's why changing declaration order or adding / removing dependencies can make the problem go away. #14229 fixes such a corner case. Once a nightly with the fix is available, I'll ask you to test it to see if it fixes this issue. |
|
Can you try with a nightly and let us know how it goes? |
|
No, unfortunately it still had a problem: This was using this version: |
|
Unfortunately we can't figure out what's going on without a reproducer, as it's a particularly difficult thing to debug. We'd appreciate if you can trip down your project/anonymize to a minimal reproducer. |
|
Unfortunately, we have a lot of internal dependencies here (with different build approaches, etc), and figuring out a reproduction case wasn't getting anywhere quickly. What I may end up doing is learning how to actually build/debug Gradle itself, so I can just locally debug this. But that's not exactly my highest priority, so I can't you when I'd get around to this. Basically, I think it's probably valid to just say "can't reproduce" and close this issue. If I actually am able to figure out what's going on, I'll re-open it with reproduction details, or reference a new ticket with a reproduction case. |
|
I just had the same problem but with |
|
@shmish111 Any chance that you are using replacement rules? |
|
Not that I'm aware of but I will try to remember to try this out once that is released. |
|
Gradle 7.3 RC1 is out already, could you check with that version? |
octylFractal
added
in:dependency-resolution
|
Having this problem even with 7.3.1 |
|
`---------- org.gradle.api.artifacts.ResolveException: Could not resolve all dependencies for configuration ':ads-engagement-summary-report-job-azkaban_2.11:compileClasspath'. Cannot do a successful build anymore after this. |
|
I have the same problem |
|
Some more fixes have landed on the main branch recently. |
|
Here is a reproducer for the problem in an error case when dynamic versions are involved. In the attached example:
This is also a problem if you write tasks that take resolution results with errors as input (using A workaround to at least keep the build working (with an empty resolution result though) is to use the following as task input: |
|
Another reproducer, this time for a successful resolution:
|
|
We had this issue trigger because of the following dependency substitution rule: Due to the project's upgrade strategy using shim jars (see https://hamcrest.org/JavaHamcrest/distributables#previous-versions-of-hamcrest), hamcrest-core now depends on hamcrest. |
|
gradle-problems-reading-binary-store also reproduces the problem. There, the problem disappears by switching the order of the only two dependencies declared in the |
|
Any ideas about things that users might be able to do to help out with this? |
|
I'm facing an issue while working on converting the AndroidX library For reference, here are the AOSP changes:
|
|
We think we found a workaround in the case of the previous comment, which is to explicitly add a transitive dependency to the androidMain sourceset from the project encountering the error ( Also interesting, if we instead add the transitive dependency to the commonMain sourceset instead, then we get a resolution ambiguity error |
* Converting `lifecycle-viewmodel-compose` to Kotlin Multiplatform, and transitively depending on `lifecycle-livedata-core` triggered a bug in Gradle (gradle/gradle#14220). * Directly adding `lifecycle-livedata-core` to `androidMain` allowed us to workaround the issue. Test: `./gradlew :lifecycle:lifecycle-viewmodel-compose:compileCommonMainKotlinMetadata -Pandroidx.constraints=true` Bug: 330323282 Change-Id: I0eb4c79efeb65e049f51706c6dcefce0d1ab83a4
* `compose-ui` has a transitive dependency on `lifecycle-livedata-core`, and converting `lifecycle-runtime-compose` to KMP triggered a Gradle bug (gradle/gradle#14220). * Directly adding `lifecycle-livedata-core` as `compileOnly` to `androidMain` allowed us to workaround the issue. Test: `./gradlew :compose:ui:ui:compileCommonMainKotlinMetadata -Pandroidx.constraints=true` Bug: 331769623 Change-Id: I463276189cf90cfca8efc46bb29ecbb64010e09e
* `compose-ui` has a transitive dependency on `lifecycle-viewmodel-savedstate`, and converting `lifecycle-runtime-compose` to KMP triggered a Gradle bug (gradle/gradle#14220). Adding the `livedata` dependency directly works around the issue. * Directly adding `lifecycle-viewmodel-savedstate` as `compileOnly` to `androidMain` allowed us to workaround the issue. Test: `./gradlew :compose:ui:ui:compileCommonMainKotlinMetadata -Pandroidx.constraints=true` Bug: 331769623 Change-Id: Ic4f81fe2737b3d61fd9b4cb02a8b940e3a0d4caf
|
Thank you all for your patience on this issue. We have been working hard on these reported problems, many of which are quite complex and trigger edge cases in the resolution engine. We have a PR, #29853, which should resolve a number of the problematic builds reported in this thread. Unfortunately, since the corrupt resolution result error message is a symptom and not a problem itself, this message can appear as a result of different bugs. The linked PR does not solve all the problems reported here. We will continue to work through the reproducers submitted here until there are no outstanding issues that cause corrupt graphs. Correctness and stability are a very high priority for Gradle, and we intend to ensure these issues are resolved. |
|
@marcellogalhardo it seems both links you posted require internal google sign-on @mathjeff Is this the same underlying issue as #26145 (comment)? |
|
I think this is the same as #26145 (comment), yeah. Thanks! |
|
Unfortunately the above linked PR has been reverted due to a regression it introduced. The fix will not be included with Gradle 8.10. We will work to include the change in 8.11 |
When executing
./gradlew dependencies --write-locks, the build fails with this error:When attempting to generate
./gradlew dependencies --scan, I receive this output:Could this be a weird local dependency problem?
Also, I did successfully run
./gradlew classes --update-locks com.vmware.carbonblackcloud:exekute. So I'm not 100% sure if that's just a red herring here or not.Expected Behavior
I would like for all of my dependencies to resolve, basically, or flag an actionable error that indicates what is the problem on my end.
Current Behavior
See the above output, it's pretty much "I can't update my lockfiles using the global command".
Context
We're using version locking, and I have several libraries I'm using, and I want to update all dependencies, to look for updates, typically to the AWS library.
Steps to Reproduce
This is challenging, because it's in a project with a whole bunch of company IP. And I can't provide a build scan for this task since that part fails, though I'm game for adding any other tasks, debugging, etc., though I bet the debug output would be ok.
Your Environment
Linux (Ubuntu 18.04), using JDK 14.0.2, and Gradle 6.6.
The text was updated successfully, but these errors were encountered: