We cache adapter Istio config to be able to request an ID token to add to HTTP requests originating from the mesh. This is a consequence of #25 which implemented a workaround to #24. However if there's a cache miss, we won't be able to add the ID token to the outbound HTTP request at hand.
Notice the Mixer passes the current config to the adapter on each mesh inbound HTTP call and the adapter caches it every time, replacing any old cached config with the most recent one. So a cache miss can only happen if
- The adapter process starts.
- An outbound HTTP request is intercepted by the Envoy filter---think Orion notification.
- The filter calls the adapter to get an ID token to add to the request.
and no mesh inbound HTTP request gets intercepted before (3). My gut tells me this isn't very likely to happen in practice, especially for high-volume sites and also considering that client requests will typically hit the mesh before a mesh service tries to call an external service---e.g. a subscription/entity update has to happen before Orion sends out a notification. However no matter how likely, the issue is there, so we might fail to inject ID tokens into outbound Orion notifications occasionally.
We should look for an easy way to solve this, e.g. in principle we should be able request current configuration from Galley or the Mixer itself so that if there's a cache miss, we would have a fallback.
We cache adapter Istio config to be able to request an ID token to add to HTTP requests originating from the mesh. This is a consequence of #25 which implemented a workaround to #24. However if there's a cache miss, we won't be able to add the ID token to the outbound HTTP request at hand.
Notice the Mixer passes the current config to the adapter on each mesh inbound HTTP call and the adapter caches it every time, replacing any old cached config with the most recent one. So a cache miss can only happen if
and no mesh inbound HTTP request gets intercepted before (3). My gut tells me this isn't very likely to happen in practice, especially for high-volume sites and also considering that client requests will typically hit the mesh before a mesh service tries to call an external service---e.g. a subscription/entity update has to happen before Orion sends out a notification. However no matter how likely, the issue is there, so we might fail to inject ID tokens into outbound Orion notifications occasionally.
We should look for an easy way to solve this, e.g. in principle we should be able request current configuration from Galley or the Mixer itself so that if there's a cache miss, we would have a fallback.