Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Graph serialization error with projects being replaced by binary dependencies #13329

Closed
cesar1000 opened this issue Jun 3, 2020 · 15 comments
Closed

Comments

@cesar1000
Copy link

@cesar1000 cesar1000 commented Jun 3, 2020

I am developing a annotation processor that runs on its own project, using a binary dependency. In order to avoid conflicts between project dependencies and binary dependencies, I'm curating my configurations carefully to isolate binary dependencies from the corresponding project dependencies. Dependency resolution, however, selects the a project dependency even if it's not present in my configuration.

Expected Behavior

The module resolution mechanism in a configuration should only draw candidates from the configuration itself. In particular, project dependencies that haven't been added to the configuration explicitly should not affect the resolution.

Current Behavior

In the current behavior, the project is added to the dependency resolution as an automatic candidate (in SelectorStateResolver, it seems), with no ability to configure. I put up a small repro of this issue here. In this example, the processor configuration contains v0.0.1 of the binary artifact. If the version of the project is set to v0.0.0, the configuration resolves the artifact to v0.0.1, but reports about a spurious conflict with v0.0.0:

image

If setting the project version to v0.0.2, the resolution selects the project, and does not report a conflict:

image

Context

In more complex projects, this seems to lead to downstream issues where the resolved project dependencies are dropped from their configurations entirely. Also, the binary store of dependencies gets corrupted in this configuration, which causes both the dependencies task and the build scan to fail with exceptions like the following:

Caused by: java.lang.RuntimeException: Problems reading data from Binary store in /private/var/folders/nr/qr07zfx91kx0mxjlg034l93h0000gp/T/gradle1279083698979558202.bin offset 28948 exists? true
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.store.DefaultBinaryStore$SimpleBinaryData.read(DefaultBinaryStore.java:132)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.result.StreamingResolutionResultBuilder$RootFactory.lambda$create$0(StreamingResolutionResultBuilder.java:187)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.store.CachedStoreFactory$SimpleStore.load(CachedStoreFactory.java:101)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.result.StreamingResolutionResultBuilder$RootFactory.create(StreamingResolutionResultBuilder.java:185)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.result.StreamingResolutionResultBuilder$RootFactory.create(StreamingResolutionResultBuilder.java:157)
        at org.gradle.api.internal.artifacts.result.DefaultResolutionResult.getRoot(DefaultResolutionResult.java:47)
        at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver$ErrorHandlingResolutionResult.getRoot(ErrorHandlingConfigurationResolver.java:201)
        ... 14 more
Caused by: java.lang.IllegalStateException: Corrupt serialized resolution result. Cannot find selected module (15) for runtimeClasspath -> project :blast:processor:test
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.result.DefaultResolutionResultBuilder.visitOutgoingEdges(DefaultResolutionResultBuilder.java:82)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.result.StreamingResolutionResultBuilder$RootFactory.deserialize(StreamingResolutionResultBuilder.java:237)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.store.DefaultBinaryStore$SimpleBinaryData.read(DefaultBinaryStore.java:130)
        ... 20 more

These issues are more involved to repro, but I can try to put something together if it helps.

Steps to Reproduce

https://github.com/cesar1000/gradle-recursive-dependency

Your Environment

I'm using Gradle v6.5.

Build scan URL:
With v0.0.0: https://scans.gradle.com/s/sba5ra5cxfcsy/dependencies?focusedDependency=WzAsMCwwLFswLDAsWzBdXV0&toggled=W1swXSxbMCwwXV0
With v0.0.2: https://scans.gradle.com/s/22nsrpchulvxw/dependencies?focusedDependency=WzAsMCwwLFswLDAsWzBdXV0&toggled=W1swXSxbMCwwXV0

@bigdaz
Copy link
Member

@bigdaz bigdaz commented Jun 3, 2020

Thanks for the detailed report. There are a couple of issues here, which I'll address separately.

Binary dependency is replaced by resolving project

First, when a configuration is declared for a project, the project module itself is always going to be the root node of the resolved configuration. So if project P configuration X has dependencies on A and B, the resolved graph is:

P -> A
 \-> B

The configuration X does not represent a module, doesn't have its own coordinates, and thus cannot exist independently in the graph. There's currently no way to use a module other than the resolving project as the resolution root.

Second, when 2 versions of the same module are present, Gradle chooses the newest one via conflict resolution.

  • This is why you get the binary dependency and see By conflict resolution : between versions 0.0.1 and 0.0.0, when the project version is 0.0.0
  • This is why you get the project dependency when the project version is 0.0.2. It's unfortunate that we don't print the conflict resolution message in that case.

Error: Problems reading data from Binary store

This issue has been reported a number of times, and we suspect there are multiple scenarios that can get Gradle into this broken state. #13316 #13251 #11844

It has proven extremely difficult to reproduce these issues reliably, so if you are able to provide a reproducer for you case, it would really help us out.

@cesar1000
Copy link
Author

@cesar1000 cesar1000 commented Jun 3, 2020

Thanks @bigdaz!

I understand from your response that the project is conceptually the root of the graph for practical reasons, which means that it needs to participate in the resolution. I don't think that's a problem in itself – the problem is that it doesn't look like there's a way to configure conflict resolution when the project is involved. The existing policies (latest module or prefer projects) can't be configured to select the binary dependency. Also, the conflict doesn't seem to be considered as such, as reflected in the absence of a conflict resolution message. I addressed this problem by removing the project version, and setting the version directly in the publication itself. Still, it would be useful for the behavior to be documented (I don't think it is?), and the response to it to be more consistent.

As for the issue with the binary store, I can repro consistently, and I'll try to set up a small reproducer. As far as I can tell, the graph resolution is dropping a bunch of valid nodes for no clear reason, but it's still emitting edges that point at the missing nodes.

@cesar1000
Copy link
Author

@cesar1000 cesar1000 commented Jun 4, 2020

Ah, it seems that the issue is caused by a combination of project and binary dependencies using BOM files, where some of the conflicts between project and binary dependencies are left unresolved. At the time of the graph resolution, the orphan nodes cause the graph traversal to be incomplete, dropping edges and leaving orphan nodes behind. The missing dependencies cause the build to fail, and the invalid graph causes the build scan to fail.

I built a reproducer from my original project and shared with @bigdaz and @jjohannes.

@bigdaz
Copy link
Member

@bigdaz bigdaz commented Jun 4, 2020

Thanks @cesar1000. I'm not going to have capacity to investigate the Binary store issue. Could you please also share your reproducer project with @ljacomet and @melix?

@cesar1000
Copy link
Author

@cesar1000 cesar1000 commented Jun 4, 2020

Done! Thanks for your direction yesterday, @bigdaz.

@ljacomet
Copy link
Member

@ljacomet ljacomet commented Jun 5, 2020

The privately shared reproducer will help a lot diagnose and fix the issue. Expect news on this early next week.
Sadly the fix for #13251 and #13316 does not fix this issue.

@cesar1000
Copy link
Author

@cesar1000 cesar1000 commented Jun 6, 2020

Awesome, thanks, Louis! Coincidentally, I just found another issue that repros in the same repo after a minor change. I think it's unrelated, so filed separately as #13353.

@ljacomet
Copy link
Member

@ljacomet ljacomet commented Jun 9, 2020

I have figured out the issue for the graph serialization issue.

However I have to admit this graph was really strange until I figured it out 😉

The initial report about the spurious conflict is real. Because the projects have no version defined, the moment a binary dependency with the same coordinates but a version enters the graph, it wins and pretty much replaces all the projects with the binary versions.
What's true is that we replace the undefined you see in module version identifiers with a 0.0.0 which can be confusing. I'll see if that could say undefined as well.

An alternative is to use resolutionStrategy.preferProjectModules() which will favor the project over binary versions.
Or, as you indicated by yourself, setting a version for the project.

The root cause of that behaviour is that the gradle-plugin project in your reproducer has a version and uses that in the plugin code itself, making that version visible into the graphs consuming it.

None of that is unexpected behavior, so once the binary store issue is fixed and the version conflict clarified, there should not be another change.

I'll follow up once I have a nightly that can be tested on the reproducer.

ljacomet added a commit that referenced this issue Jun 9, 2020
Before this change, some node that carried constraints would remain
registered as interested in pending dependencies. This could cause
invalid deferred selection.
With this set of changes, such state is cleaned up when a node that
carries constraints no longer participates in the graph, either because
it is not transitive or because it is no longer selected.

Issue #13329
@cesar1000
Copy link
Author

@cesar1000 cesar1000 commented Jun 9, 2020

Yeah, it's an unusual graph! This is a layered annotation processor that runs on itself, so I need the processor classpaths to use a binary dependency, and the runtime classpath to use the project dependency, when available, and the binary dependency otherwise. I worked around by using preferProjectModules(), as you suggested.

The behavior that I saw, however, looked unexpected: the conflicting dependencies were dropped from the configuration altogether, not just resolved to unexpected dependencies. The resulting dependency graph did not match up edges and nodes correctly, which resulted in nodes being dropped even if referenced by some of the edges (which ultimately caused the crash). This would should up in the build as compilation failures with symbols not in the classpath. Is that what you're addressing in your fix?

ljacomet added a commit that referenced this issue Jun 11, 2020
Before this change, some node that carried constraints would remain
registered as interested in pending dependencies. This could cause
invalid deferred selection.
With this set of changes, such state is cleaned up when a node that
carries constraints no longer participates in the graph, either because
it is not transitive or because it is no longer selected.

Issue #13329
@cesar1000
Copy link
Author

@cesar1000 cesar1000 commented Jun 14, 2020

I'm seeing an issue in this project where dependency resolution hangs in what seems to be an infinite loop (following a cycle in the graph?). I couldn't figure out how to isolate a repro. Before I put in any more time, is there a chance that this fix may address this kind of issue?

@ljacomet
Copy link
Member

@ljacomet ljacomet commented Jun 15, 2020

Hey @cesar1000,

You can try with the following nightly:
./gradlew wrapper --gradle-version=6.6-branch-ljacomet_dependency_management_graph_invalid_pending-20200615140556+0000
It fixes the original graph serialization issue.

@ljacomet ljacomet changed the title Recursive binary dependency is replaced with a project dependency Graph serialization error with projects being replaced by binary dependencies Jun 15, 2020
@cesar1000
Copy link
Author

@cesar1000 cesar1000 commented Jun 16, 2020

Thanks! The nightly does fix the original issue. I does not fix the dependency resolution hanging in an infinite loop though – would you want me to add a separate ticket for that? What kind of information would help troubleshoot?

If it helps, here's a dump of a full cycle in the infinite loop of dependency resolution:

Processing node: com.twitter.scythe🗡️unspecified(processor_runtime_external)
Processing node: com.twitter.scythe:bom:0.0.10(runtimeElements)
Dependency: com.twitter.scythe:annotation-processor:0.0.10
Dependency: com.twitter.scythe:common:0.0.10
Dependency: com.twitter.scythe🗡️0.0.10
Dependency: com.twitter.scythe:gradle-plugin:0.0.10
Dependency: com.twitter.scythe:processor:0.0.10
Dependency: com.twitter.scythe:runtime:0.0.10
Dependency: com.twitter.scythe:test:0.0.10
addLast: com.twitter.scythe:runtime:0.0.10(runtimeElements)
addLast: com.twitter.scythe:annotation-processor:0.0.10(runtimeElements)
addLast: com.twitter.scythe🗡️unspecified(processor_runtime_external)
Processing node: com.google.auto.service:auto-service-annotations:1.0-rc7(runtime)
Processing node: com.twitter.scythe:runtime:0.0.8(runtimeElements)
Processing node: com.google.dagger🗡️2.26(runtime)
Processing node: com.google.auto.value:auto-value-annotations:1.7(runtime)
Processing node: com.squareup.inject:assisted-inject-annotations-dagger2:0.5.2(runtime)
Processing node: com.twitter.blast.processor:javax:0.0.10(runtimeElements)
Dependency: com.twitter.scythe:runtime:0.0.8
Dependency: com.google.dagger🗡️2.26
Dependency: com.google.auto.value:auto-value-annotations:1.7
Dependency: com.squareup.inject:assisted-inject-annotations-dagger2:0.5.2
Dependency: org.jetbrains.kotlin:kotlin-stdlib:1.3.72
Dependency: com.twitter.blast.ast:javax:0.0.10
Dependency: com.twitter.blast.processor:core:0.0.10
Dependency: com.twitter.blast:bom:0.0.10
addLast: com.twitter.blast:bom:0.0.10(runtimeElements)
addLast: com.twitter.blast.processor:core:0.0.10(runtimeElements)
addLast: com.google.dagger🗡️2.26(runtime)
addLast: com.google.auto.value:auto-value-annotations:1.7(runtime)
addLast: com.squareup.inject:assisted-inject-annotations-dagger2:0.5.2(runtime)
addLast: com.twitter.blast.ast:javax:0.0.10(runtimeElements)
Processing node: com.twitter.blast.processor:javapoet:0.0.10(runtimeElements)
Dependency: com.twitter.scythe:runtime:0.0.8
Dependency: com.google.dagger🗡️2.26
Dependency: com.google.auto.value:auto-value-annotations:1.7
Dependency: com.squareup.inject:assisted-inject-annotations-dagger2:0.5.2
Dependency: org.jetbrains.kotlin:kotlin-stdlib:1.3.72
Dependency: com.twitter.blast.ast:javapoet:0.0.10
Dependency: com.twitter.blast.processor:core:0.0.10
Dependency: com.twitter.blast:bom:0.0.10
addLast: com.twitter.blast.ast:javapoet:0.0.10(runtimeElements)
Processing node: com.twitter.scythe:processor:0.0.10(runtimeElements)
Dependency: com.twitter.scythe:runtime:0.0.8
Dependency: com.google.dagger🗡️2.26
Dependency: com.google.auto.value:auto-value-annotations:1.7
Dependency: com.squareup.inject:assisted-inject-annotations-dagger2:0.5.2
Dependency: org.jetbrains.kotlin:kotlin-stdlib:1.3.72
Dependency: com.twitter.blast.processor:core:0.0.10
Dependency: com.twitter.scythe:common:0.0.10
Dependency: com.twitter.scythe:bom:0.0.10
addFirst: com.twitter.scythe:bom:0.0.10(runtimeElements)
Processing node: com.twitter.scythe:bom:0.0.10(runtimeElements)
addLast: com.twitter.scythe:common:0.0.10(runtimeElements)
Processing node: com.twitter.scythe🗡️unspecified(runtimeElements)
Dependency: org.jetbrains.kotlin:kotlin-stdlib:1.3.72
Dependency: com.squareup:javapoet:1.12.1
Dependency: project :blast:ast:javapoet
Dependency: project :blast:processor:core
Dependency: project :scythe:bom
Dependency: com.google.auto.service:auto-service-annotations:1.0-rc7
Dependency: com.twitter.scythe:runtime:0.0.10
Dependency: com.google.dagger🗡️2.26
Dependency: com.google.auto.value:auto-value-annotations:1.7
Dependency: com.squareup.inject:assisted-inject-annotations-dagger2:0.5.2
addFirst: com.twitter.scythe🗡️unspecified(runtimeElements)
addFirst: com.twitter.scythe:processor:0.0.10(runtimeElements)
addFirst: com.google.auto.service:auto-service-annotations:1.0-rc7(runtime)
addFirst: com.twitter.blast.processor:javax:0.0.10(runtimeElements)
addFirst: com.twitter.blast.processor:javapoet:0.0.10(runtimeElements)
addFirst: com.twitter.scythe:bom:0.0.10(runtimeElements)
addLast: com.twitter.scythe:bom:unspecified(runtimeElements)
addLast: com.twitter.blast.ast:javapoet:unspecified(runtimeElements)
addLast: com.twitter.blast.processor:core:unspecified(runtimeElements)
Processing node: com.twitter.scythe:bom:0.0.10(runtimeElements)
Processing node: com.twitter.blast.processor:javapoet:0.0.10(runtimeElements)
Processing node: com.twitter.blast.processor:javax:0.0.10(runtimeElements)
Processing node: com.google.auto.service:auto-service-annotations:1.0-rc7(runtime)
Processing node: com.twitter.scythe:processor:0.0.10(runtimeElements)
Processing node: com.twitter.scythe🗡️unspecified(runtimeElements)
addFirst: com.google.auto.service:auto-service-annotations:1.0-rc7(runtime)
Processing node: com.google.auto.service:auto-service-annotations:1.0-rc7(runtime)
Processing node: org.jetbrains.kotlin:kotlin-stdlib:1.3.72(runtime)
Processing node: com.squareup:javapoet:1.12.1(runtime)
Processing node: com.twitter.scythe:runtime:0.0.10(runtimeElements)
Processing node: com.twitter.scythe:annotation-processor:0.0.10(runtimeElements)
Dependency: com.google.auto.service:auto-service-annotations:1.0-rc7
Dependency: com.twitter.scythe:runtime:0.0.8
Dependency: com.google.dagger🗡️2.26
Dependency: com.google.auto.value:auto-value-annotations:1.7
Dependency: com.squareup.inject:assisted-inject-annotations-dagger2:0.5.2
Dependency: com.twitter.blast.processor:javax:0.0.10
Dependency: com.twitter.blast.processor:javapoet:0.0.10
Dependency: com.twitter.scythe:processor:0.0.10
Dependency: com.twitter.scythe🗡️0.0.10
Dependency: org.jetbrains.kotlin:kotlin-stdlib:1.3.72
Dependency: com.squareup:javapoet:1.12.1
Dependency: com.twitter.scythe:bom:0.0.10
addLast: com.twitter.scythe:runtime:0.0.8(runtimeElements)
addLast: com.google.auto.service:auto-service-annotations:1.0-rc7(runtime)
addLast: com.twitter.blast.processor:javax:0.0.10(runtimeElements)
addLast: com.twitter.blast.processor:javapoet:0.0.10(runtimeElements)
addLast: com.twitter.scythe:processor:0.0.10(runtimeElements)
addLast: com.twitter.scythe🗡️unspecified(runtimeElements)
addLast: org.jetbrains.kotlin:kotlin-stdlib:1.3.72(runtime)
addLast: com.squareup:javapoet:1.12.1(runtime)
Processing node: com.twitter.scythe🗡️unspecified(processor_runtime_external)
Processing node: com.twitter.blast:bom:0.0.10(runtimeElements)
Processing node: com.twitter.blast.processor:core:0.0.10(runtimeElements)
Processing node: com.google.dagger🗡️2.26(runtime)
Processing node: com.google.auto.value:auto-value-annotations:1.7(runtime)
Processing node: com.squareup.inject:assisted-inject-annotations-dagger2:0.5.2(runtime)
Processing node: com.twitter.blast.ast:javax:0.0.10(runtimeElements)
Processing node: com.twitter.blast.ast:javapoet:0.0.10(runtimeElements)
Processing node: com.twitter.scythe:common:0.0.10(runtimeElements)
Processing node: com.twitter.scythe:bom:unspecified(runtimeElements)
Dependency: com.twitter.scythe:annotation-processor:{require unspecified}
Dependency: com.twitter.scythe:common:{require unspecified}
Dependency: com.twitter.scythe🗡️{require unspecified}
Dependency: com.twitter.scythe:gradle-plugin:{require unspecified}
Dependency: com.twitter.scythe:processor:{require unspecified}
Dependency: com.twitter.scythe:runtime:{require unspecified}
Dependency: com.twitter.scythe:test:{require unspecified}
addLast: com.twitter.scythe:annotation-processor:0.0.10(runtimeElements)
addLast: com.twitter.scythe🗡️unspecified(processor_runtime_external)
Processing node: com.twitter.blast.ast:javapoet:unspecified(runtimeElements)
Processing node: com.twitter.blast.processor:core:unspecified(runtimeElements)
Processing node: com.twitter.scythe:runtime:0.0.8(runtimeElements)
Dependency: com.google.dagger🗡️2.26
Dependency: com.google.auto.value:auto-value-annotations:1.7
Dependency: com.squareup.inject:assisted-inject-annotations-dagger2:0.5.2
Dependency: org.jetbrains.kotlin:kotlin-stdlib:1.3.72
Dependency: com.twitter.scythe:common:0.0.8
Dependency: com.twitter.scythe:bom:0.0.8
addFirst: com.twitter.scythe:bom:unspecified(runtimeElements)
addFirst: com.twitter.scythe:runtime:0.0.8(runtimeElements)
addFirst: com.google.dagger🗡️2.26(runtime)
addFirst: com.google.auto.value:auto-value-annotations:1.7(runtime)
addFirst: com.squareup.inject:assisted-inject-annotations-dagger2:0.5.2(runtime)
addLast: com.twitter.scythe:bom:0.0.10(runtimeElements)
Processing node: com.squareup.inject:assisted-inject-annotations-dagger2:0.5.2(runtime)
Processing node: com.google.auto.value:auto-value-annotations:1.7(runtime)
Processing node: com.google.dagger🗡️2.26(runtime)
Processing node: com.twitter.scythe:runtime:0.0.8(runtimeElements)
addFirst: com.google.dagger🗡️2.26(runtime)
addFirst: com.google.auto.value:auto-value-annotations:1.7(runtime)
addFirst: com.squareup.inject:assisted-inject-annotations-dagger2:0.5.2(runtime)
Processing node: com.squareup.inject:assisted-inject-annotations-dagger2:0.5.2(runtime)
Processing node: com.google.auto.value:auto-value-annotations:1.7(runtime)
Processing node: com.google.dagger🗡️2.26(runtime)
Processing node: com.twitter.scythe:bom:unspecified(runtimeElements)
Processing node: com.google.auto.service:auto-service-annotations:1.0-rc7(runtime)
Processing node: com.twitter.blast.processor:javax:0.0.10(runtimeElements)
Processing node: com.twitter.blast.processor:javapoet:0.0.10(runtimeElements)
Processing node: com.twitter.scythe:processor:0.0.10(runtimeElements)
Processing node: com.twitter.scythe🗡️unspecified(runtimeElements)
Processing node: org.jetbrains.kotlin:kotlin-stdlib:1.3.72(runtime)
Processing node: com.squareup:javapoet:1.12.1(runtime)
Processing node: com.twitter.scythe:annotation-processor:0.0.10(runtimeElements)
Dependency: com.google.auto.service:auto-service-annotations:1.0-rc7
Dependency: com.twitter.scythe:runtime:0.0.8
Dependency: com.google.dagger🗡️2.26
Dependency: com.google.auto.value:auto-value-annotations:1.7
Dependency: com.squareup.inject:assisted-inject-annotations-dagger2:0.5.2
Dependency: com.twitter.blast.processor:javax:0.0.10
Dependency: com.twitter.blast.processor:javapoet:0.0.10
Dependency: com.twitter.scythe:processor:0.0.10
Dependency: com.twitter.scythe🗡️0.0.10
Dependency: org.jetbrains.kotlin:kotlin-stdlib:1.3.72
Dependency: com.squareup:javapoet:1.12.1
Dependency: com.twitter.scythe:bom:0.0.10
addLast: com.google.auto.service:auto-service-annotations:1.0-rc7(runtime)
addLast: com.twitter.scythe:runtime:0.0.8(runtimeElements)
addLast: com.google.dagger🗡️2.26(runtime)
addLast: com.google.auto.value:auto-value-annotations:1.7(runtime)
addLast: com.squareup.inject:assisted-inject-annotations-dagger2:0.5.2(runtime)
addLast: com.twitter.blast.processor:javax:0.0.10(runtimeElements)
addLast: com.twitter.blast.processor:javapoet:0.0.10(runtimeElements)
addLast: com.twitter.scythe:processor:0.0.10(runtimeElements)
addLast: com.twitter.scythe🗡️unspecified(runtimeElements)
addLast: org.jetbrains.kotlin:kotlin-stdlib:1.3.72(runtime)
addLast: com.squareup:javapoet:1.12.1(runtime)

Processing node: com.twitter.scythe🗡️unspecified(processor_runtime_external) # the cycle restarts here
Processing node: com.twitter.scythe:bom:0.0.10(runtimeElements)
Dependency: com.twitter.scythe:annotation-processor:0.0.10
Dependency: com.twitter.scythe:common:0.0.10
Dependency: com.twitter.scythe🗡️0.0.10
Dependency: com.twitter.scythe:gradle-plugin:0.0.10
Dependency: com.twitter.scythe:processor:0.0.10
Dependency: com.twitter.scythe:runtime:0.0.10
Dependency: com.twitter.scythe:test:0.0.10
addLast: com.twitter.scythe:runtime:0.0.10(runtimeElements)
addLast: com.twitter.scythe:annotation-processor:0.0.10(runtimeElements)
addLast: com.twitter.scythe🗡️unspecified(processor_runtime_external)
@ljacomet
Copy link
Member

@ljacomet ljacomet commented Jun 16, 2020

Great that the initial issue is confirmed fixed.

Please do open a new bug for that infinite loop issue, providing as much information as you can. A couple thread dumps could help as well.

ljacomet added a commit that referenced this issue Jun 16, 2020
Before this change, some node that carried constraints would remain
registered as interested in pending dependencies. This could cause
invalid deferred selection.
With this set of changes, such state is cleaned up when a node that
carries constraints no longer participates in the graph, either because
it is not transitive or because it is no longer selected.

Issue #13329
ljacomet added a commit that referenced this issue Jun 16, 2020
Before this change, some node that carried constraints would remain
registered as interested in pending dependencies. This could cause
invalid deferred selection.
With this set of changes, such state is cleaned up when a node that
carries constraints no longer participates in the graph, either because
it is not transitive or because it is no longer selected.

Issue #13329
@ljacomet ljacomet added this to the 6.6 RC1 milestone Jun 16, 2020
@ljacomet
Copy link
Member

@ljacomet ljacomet commented Jun 16, 2020

Closing as the fix for the underlying graph serialization problem has been fixed and merged.

@cesar1000
Copy link
Author

@cesar1000 cesar1000 commented Jun 17, 2020

Awesome, thanks! Reported #13450.

ljacomet added a commit that referenced this issue Jun 29, 2020
Before this change, some node that carried constraints would remain
registered as interested in pending dependencies. This could cause
invalid deferred selection.
With this set of changes, such state is cleaned up when a node that
carries constraints no longer participates in the graph, either because
it is not transitive or because it is no longer selected.

Issue #13329
@ljacomet ljacomet modified the milestones: 6.6 RC1, 6.5.1 Jun 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.