I am getting an error in egress (self hosted)

Thanks for reaching out, arijit. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

a participant did join the room and still I am getting the same error

Thanks — I hear you: a participant did join but you still get "Start signal not received" (412). I can help troubleshoot — a few focused checks will quickly narrow the cause. Could you confirm these details and share small excerpts of logs (timestamps are enough)? 1. Timing • Did you start the egress before or after the participant joined? Give approximate timestamps for egress start and participant join. 1. Participant state • After joining, did the participant publish any tracks (audio/video/data)? Egress may not start if no media is published. • Was the participant a normal client (not another egress/recorder or SIP gateway)? 1. Room creation flow • Did you explicitly call CreateRoom(), or did the room auto-create on first join? 1. Deployment connectivity • Is your egress service connected to the same Redis and LiveKit cluster as the room? Any recent restarts or network issues around the timestamps? 1. Egress settings • How was egress started? Share the relevant fields in the request (e.g.,

start_immediately

, `room_name`/`room_id`,

empty_timeout

,

source_type

). 1. Logs • From the LiveKit server: participant join event lines around the join time. • From the egress worker: lines around egress start to the 412 error. If you prefer, paste the three small log snippets (egress start, participant join, egress error with timestamps). I’ll look for missed signals (timing, missing published tracks, or event routing issues) and give the exact next step. Sources: Universal Egress | server-sdk-js | livekit/livekit_composite | DeepWiki | CreateRoom() is Taking Too Long | Server-side | livekit/livekit_composite | DeepWiki

when I am running the egress server locally using docker, it is working fine but the k8s deployed version is showing this error

Thanks — that difference (works in Docker, fails in k8s) is a strong hint. I’ll help you narrow it down. Please provide or confirm the following so I can pinpoint the cause quickly. What I’m responding to: the egress runs locally via Docker but in k8s the room-composite egress aborts with "Start signal not received" (412) even though a participant joins. Please check/provide these items: 1. Egress worker connectivity • Confirm the egress pod can reach the LiveKit server and the same Redis instance. In the egress pod run: ◦ curl or nc to your LiveKit API/WebSocket endpoint ◦ redis-cli PING (or equivalent) to your Redis host • Share any connection errors from those checks. 1. Redis & cluster setup • Are k8s egress pods pointed at the exact same Redis used by the LiveKit server (same host/port/password)? Mismatched Redis will cause missed signals. • If Redis is a k8s Service, confirm DNS/resolution and that no NetworkPolicy blocks traffic. 1. Environment & config differences • Paste the relevant environment variables from the working Docker container and from the failing k8s pod (mask secrets): LKLIVEKIT_URL, REDIS_URL/REDIS_ADDR, REDIS_PASSWORD, and any egress-specific values (EGRESS_*). • Confirm the egress image/version is identical in Docker and k8s. 1. Networking / DNS / CNI • Are there network policies, Istio/ingress/egress rules, or PodSecurityPolicies that could block Pod→Pod traffic or WebSocket connections? • Check for MTU issues or DNS resolution differences in k8s. 1. Logs (small excerpts are most helpful) • Egress pod logs from start to the 412 error (include timestamps). • LiveKit server logs around the same timestamps showing

participant_joined

for the room. • If you have Redis logs showing pub/sub activity at those times, include them. 1. Egress request details • How is egress being started in k8s? Provide the request payload fields: `room_name`/`room_id`,

source_type

,

start_immediately

,

empty_timeout

. • Was egress started before or after the participant joined (timestamps)? Quick checks you can run now • Restart an egress pod and tail its logs while you trigger a participant join—see whether the egress logs show it receiving the join event. • From inside the egress pod, run a small script or curl to list participants (if you have an admin endpoint) to confirm the pod can observe room state. If you paste: • the egress pod logs (start → error) and • the LiveKit server participant join log lines (same timeframe) and • the Redis connection env vars I’ll analyze them and point to the exact misconfiguration (most likely Redis/ connectivity or event routing).

here are some more logs

2025-12-27T19:54:29.903Z        INFO    egress  stats/monitor.go:145    cpu available: 2.000000 max cost: 4.000000      {"nodeID": "NE_F6wJcgynrENN", "clusterID": ""}
2025-12-27T19:54:29.911Z        INFO    egress  server/server.go:155    service ready   {"nodeID": "NE_F6wJcgynrENN", "clusterID": ""}
2025-12-27T19:56:59.401Z        INFO    egress  server/server_rpc.go:59 request received        {"nodeID": "NE_F6wJcgynrENN", "clusterID": "", "egressID": "EG_9J2qDbgScgqr"}
2025-12-27T19:56:59.402Z        INFO    egress  server/server_rpc.go:69 request validated       {"nodeID": "NE_F6wJcgynrENN", "clusterID": "", "egressID": "EG_9J2qDbgScgqr", "requestType": "room_composite", "sourceType": "EGRESS_SOURCE_TYPE_WEB", "outputType": "file", "room": "dispatch-audio-call-dcabc54d-0738-4792-a2f6-847eabd23c18", "request": {"RoomComposite":{"room_name":"dispatch-audio-call-dcabc54d-0738-4792-a2f6-847eabd23c18","audio_only":true,"Output":null,"Options":null,"file_outputs":[{"file_type":2,"filepath":"30175f6c-9219-40f9-893d-1ca4917d1c07/dcabc54d-0738-4792-a2f6-847eabd23c18.ogg","Output":{"S3":{"access_key":"{access_key}","secret":"{secret}","region":"us-east-1","bucket":"sandbox-featherhq-audio-recordings"}}}],"webhooks":[{"url":"<https://sandbox.featherhq.com/lk/webhook>","signing_key":"API25510e2982c030d7"}]}}}
2025-12-27T19:56:59.435Z        INFO    egress  redis/redis.go:144      connecting to redis     {"nodeID": "NE_F6wJcgynrENN", "handlerID": "EGH_nGiD6Tsscmfu", "clusterID": "", "egressID": "EG_9J2qDbgScgqr", "simple": true, "addr": "livekit-redis-sandbox-redis-headless.default.svc.cluster.local:6379"}
2025-12-27T19:57:01.227Z        ERROR   egress  logging/handler.go:60   irectory        {"nodeID": "NE_F6wJcgynrENN", "clusterID": "", "handlerID": "EGH_nGiD6Tsscmfu", "egressID": "EG_9J2qDbgScgqr"}
<http://github.com/livekit/egress/pkg/logging.NewHandlerLogger.func1|github.com/livekit/egress/pkg/logging.NewHandlerLogger.func1>
        /workspace/pkg/logging/handler.go:60
<http://github.com/livekit/protocol/logger/medialogutils.(*CmdLogger).Write|github.com/livekit/protocol/logger/medialogutils.(*CmdLogger).Write>
        /root/go/pkg/mod/github.com/livekit/protocol@v1.43.3-0.20251202235353-eec8df247cf9/logger/medialogutils/cmd.go:29
io.copyBuffer
        /root/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.3.linux-amd64/src/io/io.go:431
io.Copy
        /root/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.3.linux-amd64/src/io/io.go:388
os.genericWriteTo
        /root/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.3.linux-amd64/src/os/file.go:275
os.(*File).WriteTo
        /root/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.3.linux-amd64/src/os/file.go:253
io.copyBuffer
        /root/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.3.linux-amd64/src/io/io.go:411
io.Copy
        /root/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.3.linux-amd64/src/io/io.go:388
os/exec.(*Cmd).writerDescriptor.func1
        /root/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.3.linux-amd64/src/os/exec/exec.go:596
os/exec.(*Cmd).Start.func2
        /root/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.3.linux-amd64/src/os/exec/exec.go:749
2025-12-27T19:57:01.377Z        INFO    egress  source/web.go:328       chrome: END_RECORDING   {"nodeID": "NE_F6wJcgynrENN", "handlerID": "EGH_nGiD6Tsscmfu", "clusterID": "", "egressID": "EG_9J2qDbgScgqr"}
2025-12-27T19:57:02.150Z        INFO    egress  info/io.go:269  egress_aborted  {"nodeID": "NE_F6wJcgynrENN", "clusterID": "", "egressID": "EG_9J2qDbgScgqr", "requestType": "room_composite", "outputType": "file", "error": "Start signal not received", "code": 412, "details": "End reason: Source closed"}
2025-12-27T20:01:20.233Z        INFO    egress  server/server_rpc.go:59 request received        {"nodeID": "NE_F6wJcgynrENN", "clusterID": "", "egressID": "EG_uWowiW7VPgwZ"}
2025-12-27T20:01:20.234Z        INFO    egress  server/server_rpc.go:69 request validated       {"nodeID": "NE_F6wJcgynrENN", "clusterID": "", "egressID": "EG_uWowiW7VPgwZ", "requestType": "room_composite", "sourceType": "EGRESS_SOURCE_TYPE_WEB", "outputType": "file", "room": "dispatch-audio-call-06072aaa-7bda-484a-9fda-93bb2b301a52", "request": {"RoomComposite":{"room_name":"dispatch-audio-call-06072aaa-7bda-484a-9fda-93bb2b301a52","audio_only":true,"Output":null,"Options":null,"file_outputs":[{"file_type":2,"filepath":"30175f6c-9219-40f9-893d-1ca4917d1c07/06072aaa-7bda-484a-9fda-93bb2b301a52.ogg","Output":{"S3":{"access_key":"{access_key}","secret":"{secret}","region":"us-east-1","bucket":"sandbox-featherhq-audio-recordings"}}}],"webhooks":[{"url":"<https://sandbox.featherhq.com/lk/webhook>","signing_key":"API25510e2982c030d7"}]}}}
2025-12-27T20:01:20.271Z        INFO    egress  redis/redis.go:144      connecting to redis     {"nodeID": "NE_F6wJcgynrENN", "handlerID": "EGH_uftJKZmsrh9d", "clusterID": "", "egressID": "EG_uWowiW7VPgwZ", "simple": true, "addr": "livekit-redis-sandbox-redis-headless.default.svc.cluster.local:6379"}
2025-12-27T20:01:21.483Z        INFO    egress  source/web.go:328       chrome: END_RECORDING   {"nodeID": "NE_F6wJcgynrENN", "handlerID": "EGH_uftJKZmsrh9d", "clusterID": "", "egressID": "EG_uWowiW7VPgwZ"}
2025-12-27T20:01:21.632Z        INFO    egress  info/io.go:269  egress_aborted  {"nodeID": "NE_F6wJcgynrENN", "clusterID": "", "egressID": "EG_uWowiW7VPgwZ", "requestType": "room_composite", "outputType": "file", "error": "Start signal not received", "code": 412, "details": "End reason: Source closed"}

Thanks — the logs confirm the egress worker in k8s starts, connects to Redis at livekit-redis-sandbox-redis-headless.default.svc.cluster.local:6379, launches Chrome, then immediately logs "chrome: END_RECORDING" and aborts with "Start signal not received" (412). That matches the worker not seeing the participant join signal before the headless web source closes. Next focused checks — please run these and paste brief results: 1. From the egress pod, verify Redis connectivity • kubectl exec -it <egress-pod> -- redis-cli -h livekit-redis-sandbox-redis-headless -p 6379 PING ◦ paste the response. 1. From the egress pod, confirm the pod can reach the LiveKit server (WebSocket/API) • kubectl exec -it <egress-pod> -- curl -v https://<livekit-api-host>/health (or your LiveKit API URL) ◦ paste connection success or error. 1. Confirm the participant join was visible to the LiveKit server at the same time • From LiveKit server logs, paste the

participant_joined

line(s) with timestamps that match the egress attempt (around 2025-12-27T195659–195702 and 200120–200122). 1. Check for duplicate/mismatched Redis • Ensure LiveKit server and egress pods are using the exact same Redis host/port/password (show the REDIS_ADDR/REDIS_URL env from both the LiveKit server pod and the egress pod; mask secrets). 1. Reproduce with live tails • Restart one egress pod, then tail its logs while you cause a participant to join. Paste the egress log lines from pod start → join → outcome. Quick mitigations to try now • If participant was already in room before you started egress, restart egress with

start_immediately: true

. • Temporarily increase any

empty_timeout

or start egress after confirming the participant is present. • If you suspect network policies/Service DNS, try port-forwarding the Redis service to your local machine and test connectivity from the egress pod. If you paste the redis-cli PING, the LiveKit participant_joined log lines, and the REDIS env values from both server and egress pods, I’ll analyze them and point to the exact misconfiguration.