Spring circular reference error only happens some of the time, and @Lazy has no effect

I asked a recent question about Spring circular reference issues, but I didn't get anything useful from that. I'm going to restate the current problem with additional information.

I'm using Spring 5.0.9 (also tried 5.2.5) and Spring Boot 2.0.5.

When we merge code to master, a build of the same code starts on four different dev servers. Very often, sometimes on only one server, sometimes on two, we get an error like the following:

UnsatisfiedDependencyException: Error creating bean with name 'billPreferenceRestService': Unsatisfied dependency expressed through field 'componentService'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'stateManagerOperation': Unsatisfied dependency expressed through field 'addressServiceClient'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'addressServiceClient': Bean with name 'addressServiceClient' has been injected into other beans [addressInfoServiceImpl] in its raw version as part of a circular reference, but has eventually been wrapped.

It doesn't happen on the same server each time. Invariably, if we simply request the build to be rerun on that server, the error doesn't happen.

I have spent a long time looking at bean references, centering on the addressServiceClient bean, which seems to always be part of this, and I cannot find a circular reference, but it could be several levels deep, which makes it very hard to find.

We never see this error with normal testing on our laptops, it only ever happens on the build server. However, I was able to extract the fat jar that is constructed on the server and download it to my laptop, and when I execute that from the command line, it does demonstrate the same error. I've also done the same with the fat jar on builds that do NOT demonstrate the error, and it does not show the error running on the laptop. If I compare the "bad" jar with the "good" jar, I only see differences in the order of entries in the archive.

Since the AddressServiceClient always seems to be involved in this alleged cycle, I decided to add @Lazy to the class declaration. This had no effect.

After that, I set up the application so that if any parameters were passed in (normally no command-line parameters are supplied), instead of doing a normal startup of the application, it would instead execute the following loop (paraphrased somewhat from the real code):

for (BeanDefinition bd : scanner.findCandidateComponents(basePackage)) {
  String beanClassName = bd.getBeanClassName();
  System.out.println("cn[" + beanClassName + "] lazy[" + bd.isLazyInit() + "] dependsOn[" + bd.getDependsOn() + "]");
}

Note that if it executes that code, it doesn't execute the normal startup code, which is approximately this:

getSpringApplicationBuilder().sources(Application.class).run(args);

Where Application has the @SpringBootApplication annotation.

I executed the "bad" jar on my laptop with a dummy command-line argument so it would execute this code. I searched through the output for the AddressServiceClient class. The lazy flag was false (and dependsOn was null).

I suppose the the lazy flag isn't true because by not executing run() on the SpringApplicationBuilder, I skipped some bean resolution steps. I could use confirmation of that.

Note that none of our application classes are using constructor injection. Some of the constructors in some of the platform libraries we use (written by another team) are using constructor injection, but I examined each one of those, and they're either injecting simple properties or objects that couldn't possibly be in our cycle.

We are not using AOP.

I could some ideas. Don't bother suggesting that I refactor. That is pointless if I don't know what I need to refactor to solve this problem. The overall application is quite large.