BeanCreationNotAllowedException after deregistering service with consul

Describe the bug
Please provide details of the problem, including the version of Spring Cloud that you
are using.
My development environment is like below.
spring boot 2.5.13
spring boot starter consul discovery 3.0.4
spring boot starter gateway 3.0.6

i have customHealthIndicator implementing ReactiveHealthIndicator, thus, i always health down before shutdown my application.
sometimes, after health down, around 30s elapsed, i kill -15 pid(my application pid), errors are printed like below.

2024-10-29 08:09:04.313  INFO 266172 --- [SpringApplicationShutdownHook] o.s.c.c.s.ConsulServiceRegistry          : Deregistering service with consul: server:xxxxxxxxxx

2024-10-29 08:09:04.352 ERROR 266172 --- [catalogWatchTaskScheduler-1] o.s.c.gateway.route.CachingRouteLocator  : Refresh routes error !!!

org.springframework.beans.factory.BeanCreationNotAllowedException: Error creating bean with name 'defaultValidator': Singleton bean creation not allowed while singletons of this factory are in destruction (Do not request a bean from a BeanFactory in a destroy method implementation!)

2024-10-29 08:09:04.354 ERROR 266172 --- [catalogWatchTaskScheduler-1] o.s.c.c.discovery.ConsulDiscoveryClient  : Error watching Consul CatalogServices

org.springframework.beans.factory.BeanCreationNotAllowedException: Error creating bean with name 'cachedCompositeRouteLocator': Singleton bean creation not allowed while singletons of this factory are in destruction (Do not request a bean from a BeanFactory in a destroy method implementation!)

it seems my application try to generate bean after receiving shutdown signal.
how can i overcome this problem? and i'd like to identify the cause

Start with the shutdown sequence around ConsulServiceRegistry and the SpringApplicationShutdownHook, then inspect the logged CachingRouteLocator and ConsulDiscoveryClient paths. Reproduce the health-down condition followed by SIGTERM and capture whether route refresh or catalog watching continues during bean destruction. Done means the cause of the post-shutdown bean creation is identified and the observed errors have a verified resolution.