Duplicate egress triggered for a room — duplicate egress_ended webhooks before room ended, and no way to tell which egress instance sent them

Getting Started
1

Setup: voice agent on livekit-agents 1.4.6 / livekit 1.1.2 (Python), SIP, LiveKit Cloud. Room-composite egress (audio_only, DUAL_CHANNEL_AGENT, OGG → S3).

We started one room-composite egress for room RM_LSjTA3upCArD (single start_room_composite_egress call, no client retries). The session events show the egress was triggered twice for the room.

As a result we received multiple egress_ended / EGRESS_COMPLETE webhooks for the same egressId (EG_5Ef7qsW65bH9) with different startedAt/endedAt — and the first ones arrived while the room was still active (the call hadn’t ended yet), kicking off our post-call processing prematurely.

The core problem: all webhooks carry the same egressId, so there is no way to identify whether an egress_ended webhook came from the duplicated egress or the original one — or which one is final. Both also wrote to the same S3 filepath (the later one overwrote the earlier file).

Questions:

  1. Why was the egress triggered twice for one StartEgress request?
  2. How can a webhook consumer distinguish the original vs duplicated egress run (or identify the final egress_ended), given they share one egressId?

IDs (LiveKit Cloud, project p_3tqm7ro6kbs): room RM_LSjTA3upCArD, egress EG_5Ef7qsW65bH9, 2026-06-04 12:36–12:38 UTC. Session events: https://cloud.livekit.io/projects/p_3tqm7ro6kbs/sessions/RM_LSjTA3upCArD/events

2

Thanks for the detail Zaheer

Why was the egress triggered twice for one StartEgress request?

It looks like two simultaneous Egress processes were spun up, but I’m not sure why. I have flagged this internally.

How can a webhook consumer distinguish the original vs duplicated egress run (or identify the final egress_ended), given they share one egressId?

That’s not possible, because this is not intended behaviour (you should not be receiving duplicate webhooks like this, with the same ID, so it should not be up to you to distinguish them)

3

Thanks for the update. Lmk once you receive more details. Appreciate your help :folded_hands:

4

@Zaheer_Abbas whilst not a complete fix for this issue the following PR should minimize inconsistencies when this does occur: Silently exit on duplicate-identity disconnect by milos-lk · Pull Request #1251 · livekit/egress · GitHub.

The fix for the root cause is being tracked separately internally.

5

Thanks, Appreciate the update @darryncampbell

6

StartRoomCompositeEgress returns deadline_exceeded (408) — does the egress still get created server-side? (we then see duplicate egress-completion handling)

Setup: voice agents on livekit-agents 1.4.6 / livekit 1.1.2 / livekit-api 1.0.7 (Python 3.11), outbound SIP telephony, LiveKit Cloud (project p_3tqm7ro6kbs). We start a room-composite, audio-only, dual-channel egress (OGG → S3) right after the callee answers and the agent joins.

What happened (room RM_HVDLJNxUhj8R, 2026-06-08):

  • 14:07:35.728 UTC — our first StartRoomCompositeEgress call returned:

    TwirpError(code=deadline_exceeded, message=request timed out, status=408)

  • We retried, and at ~14:07:37.6 UTC the retry succeeded and returned egress EG_44t6CLtHEgMC. The call recorded normally and the audio uploaded to S3.

  • After the call ended (14:08:34 UTC), our webhook receiver ran post-egress completion processing ~5 times for this single call within ~8 seconds (14:08:39–14:08:47) — repeated downloads + transcript generations, and multiple concurrent redaction passes that collided: one wrote the redacted file successfully, another failed with "output file already exists".

We only ever observed one egress ID in our own logs (EG_44t6CLtHEgMC, from the successful retry). But the repeated completion processing makes us suspect the timed-out first StartEgress (the 408) actually created an egress server-side — one whose ID we never received (the response timed out) — which then also emitted a completion webhook. Net: one logical recording, but potentially two egress instances and two egress_ended webhooks, driving duplicated post-call processing on our side.

7

Hi Zaheer, your hypothesis sounds very plausible since I see that EG_MNpsCYyGTYiy was also spawned for this session. I would have expected your webhook to distinguish between the two egresses in this instance however since they had different IDs. This sounds like a different issue from the original issue in this thread, it looks more like the issue described here: Error during egress request - #9 by Zaheer_Abbas

I’m honestly a bit lost at this point, I want to make sure you have the support you need but it feels like there are a lot of different but related threads. Are you getting the support you need?

8

Hello Darryn,

Thanks for responding, yes this is a separate issue where in we are able to distinguish the two different egress requests.

I added in this same thread as it belongs to the same duplicate egress. We triggered a duplicate egress because the Room Compose Egress API timed out on LiveKit Cloud. Should we NOT trigger retries in this case?

Apologies for causing confusion - this is a different issue but raised in same thread because of duplicate egress being triggered. Happy to move this to a separate post.

9

https://cloud.livekit.io/projects/p_3tqm7ro6kbs/sessions/RM_34TBvzUTvsPw/events

Seeing a duplicate egress here too

10

I see that Silently exit on duplicate-identity disconnect by milos-lk · Pull Request #1251 · livekit/egress · GitHub has been merged but I don’t see that it’s yet been pushed to the cloud. Hopefully once this is pushed, these incidents will reduce. The current plan is to make a release on Monday.