According to Ian's notes in that documentation, smaller priority values are answered first ahead of the same request going to a resource at a larger priority value. So near as I can figure, whenever the Load Balancer received a request for service.civicpdx.org/housing-affordability, it matched it to the Listener whose Path was declared as "/housing*" (i.e. the ListenerRule with Priority = 7) and would send the requests there instead of to the housing-affordability container.
The big mystery is how this worked throughout the 2018 project season and through the Demo - we've always had "/housing" assigned a smaller Priority value than "/housing-affordability". I must have simplified and removed some so-called redundancy in the last week or two that inadvertently was keeping these ListenerRules from colliding.
Solution
I've simply bumped the 2017 API containers up in Priority value from the 1-10 range, to instead be assigned the 51-60 range. Problem, immediately solved.
As of a recent update to the ListenerRules in the CloudFormation stack, all requests for http://service.civicpdx.org/housing-affordability/ were being answered by the API running in the container to which we route http://service.civicpdx.org/housing/
The Priority values (as documented here) for the services were as follows:
Theory of Problem
According to Ian's notes in that documentation, smaller priority values are answered first ahead of the same request going to a resource at a larger priority value. So near as I can figure, whenever the Load Balancer received a request for service.civicpdx.org/housing-affordability, it matched it to the Listener whose Path was declared as "/housing*" (i.e. the ListenerRule with Priority = 7) and would send the requests there instead of to the housing-affordability container.
The big mystery is how this worked throughout the 2018 project season and through the Demo - we've always had "/housing" assigned a smaller Priority value than "/housing-affordability". I must have simplified and removed some so-called redundancy in the last week or two that inadvertently was keeping these ListenerRules from colliding.
Solution
I've simply bumped the 2017 API containers up in Priority value from the 1-10 range, to instead be assigned the 51-60 range. Problem, immediately solved.