Repository navigation
Add idempotency keys, Retry-After and opt-in retries - #6
Merged
Merged
Conversation
Enrolment, synchronous batch and asynchronous batch calls take an idempotency key, sent as the Idempotency-Key header, and a generator returns a random UUID v4 for it. The API replays the first outcome for an identical repeat, so a retry after a lost response cannot enrol twice. The typed API error now carries retryAfter, the seconds from a Retry-After header. Retries are off by default. When enabled with a maximum number of retries: 429 and 503 wait for Retry-After (capped, default 60 s) or an exponential backoff with jitter; network errors and other 5xx are retried only for GET, PATCH and DELETE and for keyed requests; other 4xx are never retried. Enrolment and batch calls generate one key per call when retries are on and none was given, and send it on every attempt.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Integrators had no safe way to retry: no idempotency key, no
Retry-Afteron errors, no retry policy (#2). The API now acceptsIdempotency-Keyon enrolment and batch endpoints (LiveXFace/backend#7) and replays the first outcome for an identical repeat.What changed
idempotency_key=onfaces.register,batch_register,batch_register_asynclivexface.new_idempotency_key()LiveXFaceApiError.retry_aftermax_retries(default 0) andmax_retry_delay(default 60 s)Retry-After(capped) or exponential backoff with full jitter; network errors and other 5xx are retried only for GET/PATCH/DELETE and keyed requests; other 4xx never. Enrolment and batch calls generate one key per call when retries are on and reuse it on every attempt.Verification
Retry-After: 12exposing status/code/requestId/retryAfter with one request; 503 then 201 retried after 5 s with the same generated key; dropped connection then replay with the same key; 422 not retried; caller key sent / no header when off; two distinct v4 keys; unkeyed POST not retried on a network error or 500 but retried on 503.mypy livexfaceandpytest(18 passed) on Python 3.10 and 3.12.id, and the collection held one face.Closes #2