c0c0n3
commented
4 years ago Come to think of it, I'm not sure we should spend too much time on this. In fact, the current architecture doesn't cater for reliable delivery of notifications anyway---think message queues. So we might actually fail to inject ID tokens into outbound Orion notifications occasionally for reasons that seem more likely to me:
- DAPS server is down
- Galley or Mixer call fails
and there's no easy way to recover from those in the current synchronous message passing setting.
gboege
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.