dagger: ComponentTreeDepsProcessor generates code in a non-deterministic order, breaking caching
We’re still on v2.38.1 so it’s possible this has been fixed, but I didn’t notice anything in the release notes.
We don’t have solid repro steps, but we’ve noticed that every so often, our HiltApplication_ComponentTreeDeps.java file generates a file that has the same content, but different ordering, causing an unnecessary rebuild.
It seems to happen within the aggregatedDeps property of the @ComponentTreeDeps annotation, although I don’t know that it’s limited to that.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 23
Commits related to this issue
- Change ComponentTreeDepsIrCreator to use linked set to preserve ordering of @ComponentTreeDeps.aggregatedDeps. Fixes #3006 RELNOTES=Fixes #3006:Change mutable set to linked set to preserve well defi... — committed to google/dagger by bcorso 3 years ago
- Sort dependencies in ComponentTreeDeps manually to give consistent output. Incremental processing can change the order we receive elements in our metadata package. This CL sorts our metadata deps man... — committed to google/dagger by bcorso 3 years ago
- Sort dependencies in ComponentTreeDeps manually to give consistent output. Incremental processing can change the order we receive elements in our metadata package. This CL sorts our metadata deps man... — committed to google/dagger by bcorso 3 years ago
- Sort dependencies in ComponentTreeDeps manually to give consistent output. Incremental processing can change the order we receive elements in our metadata package. This CL sorts our metadata deps man... — committed to google/dagger by bcorso 3 years ago
Playing around with it a bit, I think the order is correlated to what is being built. In particular, a clean build will always reproduce the same output, but an incremental build will produce different output depending on which sources needed to be rebuilt. IIUC, when we’re grabbing elements from a package, the most recently processed sources will appear last in the list.
Thus, we can’t hope for a well defined ordering of elements from these packages, and I think our only option here is just to manually sort them ourselves.
Thanks for reporting! I’ll look into getting a fix for this soon.
Ah, thanks I did miss the part about making the change. I am now able to reproduce it, thanks!
I think I found the culprit (or at least one of them, hard to say since we don’t have a good way to repro).
I’ll send out a fix in a bit.
The main reason I asked is because there’s two different code paths used to generate
@ComponentTreeDepsfor when the flag is enabled vs disabled. Thus, it would help to narrow down where to look if we knew if the issue happened with one, the other, or both.In general, I would recommend using
enableAggregatingTask = trueregardless (it’s on by default in Dagger 2.40+) because it makes your builds more performant and safer.If decide to start using
enableAggregatingTaskand the issue still remains that information would also help.