We have found an issue when the ctx passed into a remote call is blindly passed in as a context to an outgoing call. Endpoints that are sharded via the ringpop adapter might accidentally leak the header indicating a forwarded message. When this happens subsequent requests to sharded endpoints might unintentionally not be sharded.
The fix proposed here will prevent leaking the forwarded header to the application by not setting the header if the call is made to a non remote endpoint, and secondly remove the forwarding header from the forwarded call before dispatching it to the implementation.
Still required:
[x] Rename the header so services can protect them self without relying on other services to upgrade
[x] Change the payload of the header to a list of keys being forwarded for to make it easier in the future to implement key-consistent-forwarding
We have found an issue when the
ctxpassed into a remote call is blindly passed in as a context to an outgoing call. Endpoints that are sharded via the ringpop adapter might accidentally leak the header indicating a forwarded message. When this happens subsequent requests to sharded endpoints might unintentionally not be sharded.The fix proposed here will prevent leaking the forwarded header to the application by not setting the header if the call is made to a non remote endpoint, and secondly remove the forwarding header from the forwarded call before dispatching it to the implementation.
Still required: