Intermittent wrong filter selection with overlapping route prefixes (equal order) in Spring Cloud Gateway 4.1.6

[andresrodriguez55]

Im using Spring Cloud Gateway 4.1.6.
Routes are defined in application.properties. Two routes share the same prefix, and I’m not setting the order on the RouteDefinition.

spring.cloud.gateway.routes[0].uri=http://platform-dev.com/
spring.cloud.gateway.routes[0].predicates[0].name=Path
spring.cloud.gateway.routes[0].predicates[0].args[0]=/authentication/token/**
spring.cloud.gateway.routes[0].filters[0]=HeaderFilter
spring.cloud.gateway.routes[0].filters[1]=DedupeResponseHeader=Access-Control-Allow-Credentials Access-Control-Allow-Origin

spring.cloud.gateway.routes[1].uri=http://platform-dev.com/
spring.cloud.gateway.routes[1].predicates[0].name=Path
spring.cloud.gateway.routes[1].predicates[0].args[0]=/authentication/**
spring.cloud.gateway.routes[1].filters[0]=TokenFilter
spring.cloud.gateway.routes[1].filters[1]=HeaderFilter
spring.cloud.gateway.routes[1].filters[2]=AuthorizationFilter
spring.cloud.gateway.routes[1].filters[3]=DedupeResponseHeader=Access-Control-Allow-Credentials Access-Control-Allow-Origin

Occasionally after server restarts, requests to endpoints like /authentication/token/getToken get the wrong filters those from the broader route (routes[1]) instead of the more specific route (routes[0]). Its rare and not easily reproducible on demand.

What I observed while debugging:

• In the PropertiesRouteDefinitionLocator constructor, GatewayProperties shows the routes in the correct order.
• Later, in CachingRouteLocator.publishRefreshEvent, the signals list is in the wrong order.
• I know routes are sorted via AnnotationAwareOrderComparator. With equal order values the relative order can be arbitrary, but I dont understand why this leads to the incorrect filters being applied only sometimes.

This looks similar to a past issue that was reported and fixed in older versions:

• Preserve the relative order in which property based routes are defined #1661
• Routes defined via properties do not have their relative order preserved #1660

Im opening this bug because the top-to-bottom order of the application.properties file is not maintained when the order parameter is not present.