Idempotency and delivery outcomes
Repost dedupes on the idempotency key. Omit it and the runtime generates a stable key per operation and reuses it across retries; pass one (theidempotencyKey parameter on any send) to make a send safe to repeat.
Every failure is a RepostException carrying a stable errorCode, a best-known deliveryState, the idempotencyKey, and an isRetryable flag — never a raw server body or nested throwable. The five delivery states:
RepostConfigurationException, RepostValidationException, RepostSerializationException, RepostTransportException (connect/TLS/timeout/cancel/overload), RepostPublishException (server rejection or retryable failure), and RepostDescriptorVersionException (regenerate or upgrade).
Coroutines and cancellation
Asuspend send suspends the coroutine without blocking a thread and honours structured concurrency: cancelling the coroutine cancels the underlying operation, and the coroutine sees a native CancellationException. To reconcile after a cancellation, keep the operation handle from createdOperation(...) and read its outcome(), which settles even when the send is cancelled:
NOT_SENT; cancelling after it may have been written settles CANCELLED_UNKNOWN. Either way the operation settles exactly once and closes only the work it owns.
Bounded admission
maxInFlightOperations is a hard bulkhead, not a queue: when it is exceeded, a send fails immediately with an OVERLOADED error and NOT_SENT — treat it as backpressure, back off, and retry. The runtime never buffers unbounded work or paces your traffic.
Continue
Observability
Watch in-flight operations, dropped events, and attempt lifecycles.
Testing
Assert on outcomes and recorded requests without the network.
SDKs
The behavior every generated client shares, in every language.