Repository navigation
Preserve Idempotency-Key replay CLI guidance (draft) #94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -394,20 +394,22 @@ polymorfa message send text \ | |
| --body 'Your order shipped.' --idempotency-key order-123-shipped | ||
| ``` | ||
|
|
||
| For 24 hours after the first request, the API prevents the same key and request | ||
| For 1 hour after the first request, the API prevents the same key and request | ||
| from running the write again: | ||
|
|
||
| - A recorded success returns `409 idempotency_completed` with | ||
| `Idempotent-Replayed: true`. The CLI reports an error; the response does not | ||
| contain the original message or response body. | ||
| - A recorded server error returns its status and error code with | ||
| `Idempotent-Replayed: true`. The write may have happened. | ||
| - A finished request returns its original status and body, success or error, | ||
| with `Idempotent-Replayed: true`. A send whose response was lost prints the | ||
| original message. | ||
| - A recorded error is returned again. Correct the request and use a new key. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
For a recorded server error, replaying the error does not establish that the original write had no effect; the previous guidance explicitly warned that the write may have happened. Telling callers to correct the request and use a new key for every recorded error can therefore cause a duplicate message when the original send succeeded before an error was recorded. Limit this advice to errors known to precede execution, and retain the instruction to reconcile message events or webhooks before changing keys after a potentially side-effecting failure. Useful? React with 👍 / 👎. |
||
| - A request still running returns `409 idempotency_in_progress` with | ||
| `Retry-After`. An unrecorded outcome returns | ||
| `409 idempotency_outcome_unknown` and blocks another attempt with that key. | ||
| - Reusing a key for a changed request returns `409 idempotency_conflict`. | ||
| - If the recorded response cannot be read right now, the API returns | ||
| `503 idempotency_replay_unavailable` with `Retry-After`. Retry with the same | ||
| key; the write does not run again. | ||
| - Reusing a key for a changed request returns `422 idempotency_conflict`. | ||
|
|
||
| Keep the first response when you receive it. If the outcome is uncertain, check | ||
| If the outcome is uncertain, check | ||
| message events or webhooks before deciding whether to use a new key. A new key | ||
| does not resolve the uncertainty and can send a duplicate. See the | ||
| [Messaging retry contract](https://docs.polymorfa.com/guides/communicate/overview#retry-sends-safely). | ||
|
|
@@ -548,8 +550,8 @@ object with `name`, `language`, `category`, and `components` from `--input`, or | |
| from stdin when it is `-`. Template names and provider IDs remain strings. | ||
| Edits read `{ "components": [...] }` and return acceptance, not approval to send. | ||
| Deletion requires `--yes`. Create, edit and delete send one request and never | ||
| retry. Create and delete accept `--idempotency-key`; reuse the same key after an | ||
| unknown outcome and the API answers `idempotency_completed` instead of writing | ||
| retry. Create and delete accept `--idempotency-key`; reuse the same key after a | ||
| lost response and the API returns the original response instead of writing | ||
| again. List the catalog before resubmitting. The template routes need an active | ||
| Official API connection, including on a Hybrid Number; a Number with only a | ||
| Linked Devices connection is rejected. | ||
|
|
@@ -1716,9 +1718,9 @@ instants. List returns one complete newest-first array with no cursor. Requeue | |
| is synchronous and reports only the number moved. | ||
|
|
||
| Create, launch, pause, resume and stop accept `--idempotency-key` to deduplicate | ||
| the same request for 24 hours. A successful request repeated with the same key | ||
| returns `409 idempotency_completed`, not the original response. Changed input | ||
| returns `409 idempotency_conflict`; an in-progress or uncertain result must be | ||
| the same request for 1 hour. A request repeated with the same key returns the | ||
| original response, success or error. Changed input returns | ||
| `422 idempotency_conflict`; an in-progress or uncertain result must be | ||
| resolved before trying a new key. The SDK generates a fresh key for create and | ||
| launch when the flag is omitted. Supply an explicit key from the first attempt | ||
| to reuse it across CLI invocations with the same input, credential and API | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the one-hour API window documented here, users following several command help descriptions are still told that retries have “24-hour retention”: this remains in
src/commands/message/send/text.ts:24, the shared send flags insrc/input/message-send.ts:26, the payment-order flags insrc/input/payment-order.ts:15, and campaign create/launch help. A caller retrying a message after, for example, two hours can therefore follow the advertised retention period yet execute another send because the key has expired. Update the remaining Messaging idempotency help alongside this window change so it does not promise protection for an additional 23 hours.Useful? React with 👍 / 👎.