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 each hey bulk-compose row).- 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.
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 composecreates 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).replayed: true.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.