Skip to content

Setting spring.reactor.context-propagation has no effect when lazy initialization is enabled #45853

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

Closed
wants to merge 1 commit into from

Conversation

nosan
Copy link
Contributor

@nosan nosan commented Jun 8, 2025

See #45846

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jun 8, 2025
@nosan nosan force-pushed the 45846 branch 2 times, most recently from 4ba4652 to 9b2aee5 Compare June 8, 2025 14:25
@nosan
Copy link
Contributor Author

nosan commented Jun 8, 2025

I was initially thinking of the following approach:

@AutoConfiguration
@ConditionalOnClass(Hooks.class)
@ConditionalOnProperty(name = "spring.reactor.context-propagation", havingValue = "auto")
@EnableConfigurationProperties(ReactorProperties.class)
public class ReactorAutoConfiguration {

	ReactorAutoConfiguration() {
		Hooks.enableAutomaticContextPropagation();
	}

	@Bean
	static LazyInitializationExcludeFilter reactorLazyInitializationExcludeFilter() {
		return LazyInitializationExcludeFilter.forBeanTypes(ReactorAutoConfiguration.class);
	}

}

However, ReactorProperties will stop being registered, which makes this approach somewhat risky to merge.

As a good alternative, maybe something like this:

@AutoConfiguration
@ConditionalOnClass(Hooks.class)
@EnableConfigurationProperties(ReactorProperties.class)
public class ReactorAutoConfiguration {

	@Configuration(proxyBeanMethods = false)
	@ConditionalOnProperty(name = "spring.reactor.context-propagation", havingValue = "auto")
	static class ReactorContextPropagationConfiguration {

		ReactorContextPropagationConfiguration() {
			Hooks.enableAutomaticContextPropagation();
		}

		@Bean
		static LazyInitializationExcludeFilter reactorContextPropagationLazyInitExcludeFilter() {
			return LazyInitializationExcludeFilter.forBeanTypes(ReactorContextPropagationConfiguration.class);
		}

	}

}

@wilkinsona
Copy link
Member

Arguably, we shouldn't be relying on a side-effect of the constructor being called to configure the hooks and I'd prefer to use a specific callback mechanism instead. For example, implementing SmartInitializingSingleton and configuring the hooks in afterSingletonsInstantiated fixes the problem without the need for an exclude filter.

Flagging for team attention as I'm not 100% sure that SmartInitializingSingleton is the ideal callback here. @snicoll in particular may have an alternative suggestion.

@wilkinsona wilkinsona added the for: team-attention An issue we'd like other members of the team to review label Jun 9, 2025
@nosan
Copy link
Contributor Author

nosan commented Jun 9, 2025

Thanks, @wilkinsona

SmartInitializingSingleton is a decent option. However, it has one downside: enableAutomaticContextPropagation will not be visible to other SmartInitializingSingleton beans, whereas the constructor-based approach does not have such an issue. The following test demonstrates the issue:

	@Test
	void propagationShouldBeAppliedToSmartInitializingSingletonBeans() {
		this.contextRunner.withPropertyValues("spring.reactor.context-propagation=AUTO")
			.withInitializer(
					(context) -> context.addBeanFactoryPostProcessor(new LazyInitializationBeanFactoryPostProcessor()))
			.withBean(VerySmartSingleton.class)
			.run((context) -> assertThat(context.getBean(VerySmartSingleton.class).getValue()).isEqualTo("updated"));
	}

	static class VerySmartSingleton implements SmartInitializingSingleton {

		private final AtomicReference<String> threadLocalValue = new AtomicReference<>();

		String getValue() {
			return this.threadLocalValue.get();
		}

		@Override
		public void afterSingletonsInstantiated() {
			Mono.just("test")
				.doOnNext((element) -> this.threadLocalValue.set(THREADLOCAL_VALUE.get()))
				.contextWrite(Context.of(THREADLOCAL_KEY, "updated"))
				.block();
		}

	}

@wilkinsona
Copy link
Member

Indeed. That's why it may not be ideal. There are still ordering concerns with the constructor-based approach as it leaves a window between a bean using Reactor during its standard creation/initialization and ReactorAutoConfiguration being created. However, using SmartInitializingSingleton widens the window.

@nosan
Copy link
Contributor Author

nosan commented Jun 9, 2025

There are still ordering concerns with the constructor-based approach as it leaves a window between a bean using Reactor during its standard creation/initialization and ReactorAutoConfiguration being created.

How about that one?

@AutoConfiguration
@ConditionalOnClass(Hooks.class)
@EnableConfigurationProperties(ReactorProperties.class)
public class ReactorAutoConfiguration {

	@Configuration(proxyBeanMethods = false)
	@ConditionalOnProperty(name = "spring.reactor.context-propagation", havingValue = "auto")
	static class ReactorContextPropagationConfiguration {

		@Bean
		static BeanFactoryInitializer<ListableBeanFactory> reactorContextPropagationBeanFactoryInitializer() {
			return (beanFactory) -> Hooks.enableAutomaticContextPropagation();
		}

	}

}
	

This commits registers LazyInitializationExcludeFilter to exclude
ReactorAutoConfiguration from global lazy init

Signed-off-by: Dmytro Nosan <[email protected]>
@mhalbritter
Copy link
Contributor

Oh, sorry @nosan, i missed your latest update and have implemented the same solution in e2571a4.

@mhalbritter mhalbritter added status: declined A suggestion or change that we don't feel we should currently apply and removed for: team-attention An issue we'd like other members of the team to review status: waiting-for-triage An issue we've not yet triaged labels Jun 23, 2025
@nosan
Copy link
Contributor Author

nosan commented Jun 23, 2025

No worries, @mhalbritter 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants