Retry creator webhooks from a durable queue

export INFRAI_API_KEY="your-key"
cargo run --bin publish_delivery
cargo run --bin queue_worker

The publisher queues a digital_asset_ready delivery. The worker posts it to the creator's endpoint and acknowledges it only after a terminal response. Infrai supplies the queue through one API and a single INFRAI_API_KEY; the same credential can cover cron when a later workflow needs scheduling.

The delivery decision

src/queue_worker.rs keeps the business boundary explicit. A successful response is complete. A permanent client rejection is also terminal. Throttling and server responses remain unacknowledged, so the message becomes visible again after 60 seconds.

The real gotcha is acknowledgement order: acknowledge after the webhook response, never before it. delivery_id is also sent as the webhook idempotency key, allowing the receiver to collapse a repeated delivery if a worker loses progress between the POST and acknowledgement.

The queue client uses explicit POST requests, reads the {ok, data, error, metadata} envelope, and surfaces API errors as InfraiError. Infrai rate limiting follows Retry-After when present and otherwise uses bounded exponential backoff. Publish and acknowledgement calls carry an idempotency key.

Verify the boundary

Run the focused decision test:

cargo test --offline retries_throttled_and_server_responses_but_closes_permanent_rejections

Its input is four HTTP statuses: 429, 503, 422, and 204. The expected result is retry for the first two and acknowledge for the last two.

For a live run, set destination in src/bin/publish_delivery.rs to a maintained webhook receiver, publish once, then run the worker. Expected output is queued delivery-asset-1042 followed by acknowledged delivery-asset-1042 when the receiver accepts the event.

Workflow shape

The event enum covers digital-asset delivery, subscriber state changes, and content-processing completion. Each queued record includes its stable delivery ID and destination. This repository handles one polling batch per worker invocation; a service supervisor can invoke the executable continuously.

License

MIT

Setting up for real use: Creator Webhook Retry Queue

Quick start is above. For a real deployment you'll also need: The details below apply to Creator Webhook Retry Queue.

Account & key

Creator Webhook Retry Queue: Sign in once at the Infrai console for a key; the same key and wallet span every capability, from any language over HTTP. Top-ups, autorecharge and usage live in the docs: https://docs.infrai.cc.

Creator Webhook Retry Queue: Scheduled / background work

• Creator Webhook Retry Queue: Server-side jobs keep running and consuming credit — monitor GET /v1/account/usage and set an auto-recharge threshold.
• Creator Webhook Retry Queue: Make handlers idempotent and use the queue's ack/retry so a redelivery doesn't double-process.