[BUG REPORT]: Route emitters incorrectly emit unregistration messages when binding or unbinding route services

[flawedmatrix]

Summary

When a user runs cf bind-route-service or cf unbind-route-service for an application, the app will fluctuate being routable for 30 seconds to being unreachable (404 status code from the router) for 30 seconds. This behavior continues for 10 minutes, after which the app will be consistently routable again.

Expected Result

Binding or unbinding a route service should not cause the app to 404.

Diego repo

https://github.com/cloudfoundry/route-emitter

Context

This issue occurs in versions of diego-release v2.34.0 and above.

Here is a slack thread (sorry, Pivotal only) that has more context on the issue.

Possible Causes or Fixes (optional)

The mechanism to kick unregistration messages out of the route-emitter's unregistration cache should be broader to allow matching routes without route service URLs to kick out routes with route service URLs and vice versa.

[sunjayBhatia]

So a solution to this could be to omit the route-service URLs from the unique hash we compute for our unregistration cache

what happens if the route service url changes, not just added/removed but changed (can that happen? or do you have to unbind and rebind with a different service - that is my guess)

[sunjayBhatia]

Can you bind multiple route services to an app? I guess that doesn't make sense!

[sunjayBhatia]

PR: cloudfoundry/route-emitter#15

I believe all the logic that is required is to omit the route service url from the hash:

• route service is bound to app
• route service is unbound (unregistration cache has an entry added)
• route service is re-bound with a different route (unregistration cache gets a hit now b/c we've only made app id, uri, and port/tls port hashed, before it would not; cache entry is cleared)

any routes that are not route service routes would not be affected, they have an empty string for the route service url, only one route is present per registration message, so we are safe with many routes attached to an app

[sunjayBhatia]

would be great if someone reviewed that PR, reproed the issue in an environment with route services enabled, and saw that the change fixed the issue

[goonzoid]

I had a play with this. From what I can tell, it fixed the issue, so I merged the PR and bumped in diego-release.

Let's wait until it's through CI and someone else has had a chance to validate before closing this issue though.

[aminjam]

The fix for this will be shipped in Diego v2.45.0