Load balancer continues routing requests after removing all Eureka instances

Describe the bug
I'm experiencing an issue with Spring Cloud Gateway where requests are still being routed through the load balancer even after removing all instances from Eureka.

Steps to reproduce:

1. Initially had services registered with Eureka via Sidecar
2. Removed all Sidecar instances, which should have deregistered them from Eureka
3. Confirmed that no instances are listed in Eureka

Current behavior:

• Requests are still being routed through the load balancer (lb://) to the removed instances
• This continues even though there are no registered instances in Eureka

Expected behavior:

• Once all instances are removed from Eureka, the load balancer should not route requests to these non-existent instances
• The routing should fail or handle the absence of instances appropriately

Could you please help identify why the load balancer continues to route requests even after all instances have been removed from Eureka?

Sample
this is config settings

        - id: core-router
          uri: lb://CORE
          predicates:
            - Path=/core/**
          filters:
            - RewritePath=/core/(?<segment>.*), /core/$\{segment}

eureka:
  instance:
    instance-id: local-core
    prefer-ip-address: true
    ip-address: xxx.xxx.xxx.xxx
    secure-port-enabled: false
    non-secure-port-enabled: true
    non-secure-port: 8080
    lease-expiration-duration-in-seconds: 2
    lease-renewal-interval-in-seconds: 1
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: OOO1.com/eureka, OOO.com/eureka

sidecar:
  health-uri: http://xxx.xxx.xxx.xxx:8080/core/actuator/health
  ip-address: xxx.xxx.xxx.xxx
  port: 8080
  secure-port-enabled: false

Start by reproducing the lb://CORE route with the supplied Eureka and Sidecar settings, then inspect how Spring Cloud Gateway handles service instances after deregistration. Done means requests are no longer routed to removed instances and the absence of available instances is handled as expected.