hey compose: idempotency key so a rerun does not send twice
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start by tracing the hey compose and hey bulk-compose entry points and how they construct send requests. Determine where the server-side idempotency guarantee can be represented, then verify the documented replay, conflict, race, and 24-hour retention behavior; done means duplicate retries do not send another message.
Written by the indexing model from the issue text.
Description
Context
A send script's only record that a message left is local. If that record is missing, or two workers compose the same recipient and subject, hey compose creates another message. There is no server-side key the CLI can pass to make the second call a no-op.
#469 (a sent listing) is the read-side check. This is the write-side guarantee, including the race where both callers search before either send exists.
No account-specific details below.
Ask
hey compose --idempotency-key <string>(and the same field on eachhey bulk-composerow).- The same key, same account, and same resolved sender returns the original send instead of creating another: same thread id, envelope, and timestamp, with a flag such as
replayed: true. - A different body or recipient with a reused key fails with a structured conflict, rather than sending.
- Keys are remembered long enough to cover a retry of the same batch (at least 24 hours).
Why it matters
Rerunning a batch after a crash, or running it twice, should be safe. A local log is not a substitute for the server refusing the duplicate.
Related: #468, #469.
- Dominant language
- Go
- Stars
- 376
- Forks
- 44
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 130
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from basecamp/hey-cli
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
Difficulty 4/5 3-5 days Newbie friendliness 65/100
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
-
Difficulty 5/5 Over a week Newbie friendliness 48/100
All issues in basecamp/hey-cli
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
enhancement needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
kubernetes-sigs/kueue#15947 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·