revalidation of OpenFeign config clients does not work all the time

[martinlippert]

I have:

@FeignClient(name = "something", configuration = {TestConfigClass.class, FeignConfigExample.class})

when I remove FeignConfigExample.class and keep everything else, the source for FeignConfigExample is not re-validated (but it should).

When I remove the complete config attribute and turn this into:

@FeignClient(name = "something")

the re-validation of FeignConfigExample happens just fine.

[martinlippert]

One thing that I observed and can be reproduced:

• I have a class without @Configuration, but with a @Bean method
• validation shows that there is @Configuration missing (correct)
• quick fix show two options (add config in file or project) (correct)

Now I add @LoadBalancerClient annotation to another class without referencing the config class above.

• the class without the @Configuration is not re-validated - since there is no relationship between those two classes yet

When I manually trigger a re-validation, the additional quick fix appears (to add the class to the @LoadBalanderClient annotation)

[martinlippert]

One thing that I observed and can be reproduced:

• I have a class without @Configuration, but with a @Bean method
• validation shows that there is @Configuration missing (correct)
• quick fix show two options (add config in file or project) (correct)

Now I add @LoadBalancerClient annotation to another class without referencing the config class above.

• the class without the @Configuration is not re-validated - since there is no relationship between those two classes yet

When I manually trigger a re-validation, the additional quick fix appears (to add the class to the @LoadBalanderClient annotation)

Fixing this specific case would be quite difficult at the moment, since we don't know which other classes to mark for re-validation just because of the (new) existence of the @LoadBalancerClient annotation. In the end, we don't even know that this annotation is the piece that got added or changed in that class.

[martinlippert]

One thing I found is:

• the dependencies in the DependencyTracker is updated right at the end of the scanAST method
• this happens before scanAffectedFiles happens

This means that when I change the code of a file with a dependency and I change the code in a way that removes the dependency, the dependency tracker is immediately updated for this file to have no dependencies anymore. Then, scanAffectedFiles doesn't find those dependencies anymore.

Another aspect to this is:
Calls to calculate documentSymbols also calls scanAST, which then also updates the dependency tracker, even though there is no reconciling happening and no cache update going on. We need to evaluate whether the dependency tracker update should only happen in conjunction with a reconcile. But this connection between reconcile and the dependency update also sounds a bit strange to me. Looks like we need to look deeper into the dependency tracking, indexing, and document symbol creation to arrive at a cleaner design here.