You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Writes retried on DEADLINE_EXCEEDED can double-apply because the server may have already committed the change before the client's timeout fired. This change makes the safe behavior the default and puts the opt-in cost on the caller.
- Read operations retry on UNAVAILABLE, DEADLINE_EXCEEDED, and RESOURCE_EXHAUSTED — safe since reads have no side effects.
- Write operations retry on UNAVAILABLE only by default.
- Write retries on DEADLINE_EXCEEDED are unlocked by passing an `idempotencyKey` option, signalling the operation is safe to repeat.
- `retryableCodes` in ClientOptions still overrides both defaults when set explicitly.
Closes#46
Copy file name to clipboardExpand all lines: docs/configuration.md
+17-1Lines changed: 17 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -93,6 +93,22 @@ certificate store.
93
93
94
94
The SDK retries transient gRPC errors with exponential backoff and jitter.
95
95
96
+
### Read vs write retry defaults
97
+
98
+
Read operations (`get`, `getAll`) retry on `UNAVAILABLE`, `DEADLINE_EXCEEDED`, and `RESOURCE_EXHAUSTED`. These are safe to retry because reads have no side effects.
99
+
100
+
Write operations (`set`, `setMany`, `setNull`) retry only on `UNAVAILABLE` by default. `DEADLINE_EXCEEDED` is excluded because the server may have already applied the write — retrying without a guarantee of idempotency can cause duplicate mutations.
101
+
102
+
To enable `DEADLINE_EXCEEDED` retries for a write, pass an `idempotencyKey`. This signals that the caller has ensured the write is safe to repeat (e.g. the value is the same as what the server would have written):
0 commit comments