Skip to content

fix: Send one Idempotency-Key on every POST and its retries - #457

Merged
thompsongl merged 3 commits into
mainfrom
fix/idempotency-key-on-post
Oct 23, 2026
Merged

thompsongl merged 3 commits into
mainfrom
fix/idempotency-key-on-post

Conversation

@thompsongl

Copy link
Copy Markdown
Contributor

Description

Every POST now carries an Idempotency-Key, generated once before the first attempt and reused on every retry. Before, the SDK retried POSTs on connection errors and 429/5xx responses but only sent a key when the caller supplied one. If the first attempt created something but its response was lost, the retry looked like a brand-new request.

That matters now that the API deduplicates by key on Pipes explicit adds (createDataIntegrationApiKey, createDataIntegrationClientCredential, and the create*ConnectedAccount imports with connectionIntent: 'add'), not just audit log events. A retried add could create a second connected account holding live credentials. Go, Python, and .NET already key the first POST.

  • A caller's key still wins, whether passed as RequestOptions(idempotencyKey: ...) or as an Idempotency-Key extra header (matched case-insensitively).
  • PUT, PATCH, GET, and DELETE are unchanged.
  • The README gains a "Retries and idempotency" section; it had none.

Proof: testPostRetriesReuseOneGeneratedIdempotencyKey fails on main (both attempts go out with an empty Idempotency-Key) and passes here (both attempts carry the same key). testPostKeepsCallerIdempotencyKeyFromExtraHeaders guards the new branch that keeps a caller's header key.

Documentation

Does this require changes to the WorkOS Docs? E.g. the API Reference or code snippets need updates.

[ ] Yes

No WorkOS Docs change needed; the README is updated here.

🤖 Generated with Claude Code

The SDK retried POSTs on connection errors and 5xx responses but only sent
an Idempotency-Key when the caller supplied one, so a retry after a lost
response could create a duplicate, including on Pipes explicit adds, where
the API deduplicates by key. Generate one key per POST before the first
attempt and reuse it on every retry; a caller's key, through RequestOptions
or an Idempotency-Key extra header, still wins.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@thompsongl
thompsongl requested review from a team as code owners October 19, 2026 18:36
@thompsongl
thompsongl requested a review from dandorman October 19, 2026 18:36
@greptile-apps

greptile-apps Bot commented Oct 19, 2026 •

Copy link
Copy Markdown
Contributor

RetriggerView in GreptileConfidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable issues remain.

Summary

Every POST now gets a caller-supplied or generated Idempotency-Key. The SDK chooses it before the first attempt and reuses it on retries.

  • POST retries keep one idempotency key from the first attempt.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["POST request"] --> B{"Caller supplied a key?"}
    B -->|Yes| C["Keep caller key"]
    B -->|No| D["Generate one key"]
    C --> E["Send request"]
    D --> E
    E --> F{"Retry needed and allowed?"}
    F -->|Yes| E
    F -->|No| G["Return response or throw error"]
Loading

Reviews (4) · Last reviewed commit: "Merge remote-tracking branch 'origin/mai..." · Reviewed by Greptile

Comment thread README.md
Comment thread tests/HttpClientTest.php Outdated
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…n-post

# Conflicts:
#	tests/HttpClientTest.php
@thompsongl
thompsongl merged commit 8e82d9d into main Oct 23, 2026
11 checks passed
@thompsongl
thompsongl deleted the fix/idempotency-key-on-post branch October 23, 2026 17:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants