> What would happen if the orchestrator was unable to update the remote shared cache outbox after a local exception/rolled back transaction
To be sure, I understand your question, you are referring to the following scenario:
- Start global transaction
- Create shared cache entry
- Add events to the shared cache
- Local transaction fails
- Orchestrators starts rolling back local transaction
- Attempts to delete shared cache entry <-- THIS ONE FAILS
To ensure we don't have stale events in the cache, I would add a TTL, which is configurable for each job (such that you can have long-living events). So in case the orchestrator fails to delete the cache entry, they would be invalidated at some point by exceeding its TTL.
To be sure, I understand your question, you are referring to the following scenario:
- Start global transaction
- Create shared cache entry
- Add events to the shared cache
- Local transaction fails
- Orchestrators starts rolling back local transaction
- Attempts to delete shared cache entry <-- THIS ONE FAILS
To ensure we don't have stale events in the cache, I would add a TTL, which is configurable for each job (such that you can have long-living events). So in case the orchestrator fails to delete the cache entry, they would be invalidated at some point by exceeding its TTL.