authzed
Add Idempotency Support
Description:
Based on a conversation between @yordis and @vroldanbet in Discord, there seems to be a need for first-class idempotency support in the WriteRelationship API.
This is crucial for achieving reliable operations, especially in scenarios involving event processing retries, and ensuring the linearization of processing.
Context:
The WriteRelationship API already supports batch writes of relationships, which allow transactional creation, touching, or deletion of relationships. However, there are challenges around ensuring idempotent writes, especially when there could be serialization conflicts if transactions overlap.
In scenarios described by Yordis Prieto:
T1: Add Relationship - takes too long. T2: Remove Relationship - happens faster than T1. T1: Timeout - timeouts. T1: Retry Add Relationship - redo. In such a case, the sequence of operations can lead to unexpected results.
Suggested Solution:
A proposed solution by @vroldanbet is to combine CREATE with an idempotency key. By doing this, if the WriteRelationships operation fails because the idempotency-key-relationship already exists, it would signify that the operation was previously carried out.
However, this solution has limitations. For instance, it returns an error result, and we don't get the zedtoken returned by the operation.
Proposal
Integrate first-class support for idempotency keys in the WriteRelationship API. Ensure that with the idempotency key, repeated calls to WriteRelationship with the same key will result in the same effect without unintended side effects.
A proposed solution by @vroldanbet is to combine CREATE with an idempotency key. By doing this, if the WriteRelationships operation fails because the idempotency-key-relationship already exists, it would signify that the operation was previously carried out. However, this solution has limitations. For instance, it returns an error result, and we don't get the zedtoken returned by the operation.
Have you considered a solution where repeated calls with the same key would return the same exact response as the original request? That's the most common implementation of idempotency keys, and would not have the issue with zedtoken.
Have you considered a solution where repeated calls with the same key would return the same exact response as the original request? That's the most common implementation of idempotency keys, and would not have the issue with zedtoken.
This could be possible but leads to a situation where the client stores the replayed zedtoken, and ends up with an older zedtoken stored in their DB, which opens up the "new enemy problem".
