Thanks — I can help with that. A couple quick clarifying questions so I give the correct steps: 1. Which egress server are you using (LiveKit egress, custom service, or a 3rd-party egress)? 2. What messaging/queue mechanism are you using to send the egress task (e.g., RabbitMQ, SQS, Pub/Sub, Kafka, HTTP webhook, or another system)? 3. When you say “disconnected,” do you mean the egress process crashed, the server becomes unreachable on the network, or the egress connection to LiveKit was lost? 4. Do you need the requeue to be automatic (retry policy) or manual (operator-triggered)? With those details I’ll provide a concise, actionable requeue strategy (examples for retry policies, idempotency, and safe re-enqueue patterns). , with interactive elements

Thanks — I see your snippet that calls

lkapi.egress.start_room_composite_egress

and logs

egress.start_failed

on exceptions. Below is a concise, safe pattern you can apply to requeue/retry when the egress server disconnects. Key points first • LiveKit egress does not auto-requeue failed start requests. Retry from your backend. • Use an idempotency key so retries won’t create duplicate recordings. • Prefer exponential backoff + a max attempts limit. • For durability use a persistent queue/job store (Redis/RabbitMQ/SQS/DB) so retries survive process restarts. • Use egress webhooks (

egress_started

,

egress_ended

) as the source of truth: if no

egress_started

webhook arrives, it’s safe to retry. Suggested minimal changes (pseudo-Python) 1. Add an idempotency key to the request metadata (generate and persist it with the job). 2. On exception, enqueue the job into a durable queue instead of dropping it. 3. Worker consumes the queue, retries with exponential backoff and stops after N attempts. 4. Before each retry, check whether an

egress_started

webhook for the idempotency key / request has already arrived. Example outline (concise) • Generate idempotency key and persist with request record. • Try synchronous start once. • On failure, push job to persistent queue with attempt=1. • Worker loop: a. Pop job. b. If attempts > MAX -> mark failed and alert. c. Call

start_room_composite_egress

with same idempotency key. d. If success -> done. e. If fails -> increment attempts, schedule requeue after backoff (sleep or delayed queue). Idempotency details • Store idempotency key with any output location metadata (S3 path) and job state. • If a start call actually succeeded but the client didn't observe it, webhook

egress_started

will arrive—use that to mark job complete and avoid retrying. Backoff suggestion • Exponential backoff: 1s, 2s, 4s, 8s… cap at 30–60s and max attempts 5–8 depending on tolerance. If you want, I can: • Provide a concrete, tested Python snippet (integrated with Redis or RQ/Celery) that wraps your posted function and implements idempotency + retries + webhook-checking. Which queue/backend would you prefer?, with interactive elements