Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Worker panics (FFI Panic: ReadyForRoomEventRequest timeout) when two jobs' ctx.connect() run concurrently, killing all jobs on the worker

オープン
  • 何か問題がありますか？
#7,545 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
python
領域
backend

調査の方向性

Start with the minimal JobContext-only entrypoint in the issue and reproduce using two lk dispatch create calls to different rooms about a second apart. Then trace ctx.connect() and the room-connection path around the ReadyForRoomEventRequest timeout. Done means both jobs connect concurrently without a worker panic or a permanent hang, and both remain active.

索引モデルが issue の本文から書いたものです。

説明

Summary

Worker process crashes with a native FFI panic when two jobs' ctx.connect() calls happen within ~1 second of each other in the same worker. This reliably kills every active job on that worker, including ones that were already connected and running fine.

Tested with a non-conversational, JobContext-only entrypoint (no AgentSession, no voice pipeline) — a "programmatic participant" per the docs pattern in Job lifecycle. Repro does not require any real media/webcam — just two lk dispatch create calls to two different rooms a second apart.

Environment

  • livekit-agents 1.8.3
  • livekit (rtc/ffi) 1.1.18
  • OS: Windows 11
  • Python 3.13.3
  • Reproduced with both lk agent dev and lk agent start (i.e. not dev-mode-specific)

Minimal repro entrypoint

from livekit.agents import AgentServer, AutoSubscribe, JobContext, cli

server = AgentServer()

@server.rtc_session(agent_name="my-agent")
async def my_agent(ctx: JobContext) -> None:
    await ctx.connect(auto_subscribe=AutoSubscribe.SUBSCRIBE_ALL)

if __name__ == "__main__":
    cli.run_app(server)

Repro steps

  1. lk agent dev (or lk agent start) to register the worker.
  2. Fire two dispatches to two different, brand-new rooms within ~1 second of each other: 
    lk dispatch create --room concurrency-test-a --agent-name my-agent &
lk dispatch create --room concurrency-test-b --agent-name my-agent &
wait
  3. The first job connects fine. ~10-20s later, the second job's connection attempt panics the whole worker process.

Actual behavior

WARNING livekit.agents - The room connection was not established within 10 seconds after calling job_entry. ... {"room": "concurrency-test-a"}
ERROR livekit - livekit_ffi::server::room:261:livekit_ffi::server::room - timed out waiting for ReadyForRoomEventRequest after ConnectCallback (room_handle=8)
FFI Panic:  invalid request: timed out waiting for ReadyForRoomEventRequest after ConnectCallback (room_handle=8)
[exited with code 15]

The entire worker process exits — this also takes down the other, already-healthy job that was connected to concurrency-test-a.

Reproduced 3/3 times: twice under lk agent dev, once under lk agent start (production mode). Confirmed not specific to our own agent code, since it reproduces with the near-bare entrypoint above and no real participants/media.

Attempted workaround (partial, still broken)

We tried serializing ctx.connect() calls to avoid the race:

  1. asyncio.Lock() at module scope — fails immediately with RuntimeError: <asyncio.locks.Lock object ...> is bound to a different event loop, because each job clearly runs in a separate OS process (confirmed via tasklist/pid), so an in-memory lock can't coordinate across them.
  2. Cross-process file lock (filelock package) — this avoids the panic, but introduces a new failure: the job holding the lock's ctx.connect() call never returns (no exception, no log line at all after Lock ... acquired), even though the participant shows as ACTIVE in lk room participants list. The lock is then held forever, and every subsequent job spins forever retrying acquire() (never timing out, never erroring).

So today there's no way to run multiple concurrent jobs on one worker without either a process-killing panic or a silent permanent hang.

Why this matters

We're building an exam-proctoring agent (candidate video joins a room, agent watches for face-count/etc.) where multiple concurrent exam sessions per worker is the normal case, not an edge case. This bug currently makes that entirely unworkable — one candidate joining while another's session is active can silently take down every other active exam session on the same worker.

Happy to provide the full agent code, logs, or a minimal repo reproducing this if useful.

主要言語
Python
スター
14.6k
フォーク
3.9k
平均マージ
2日 17時間
マージ済み PR（30日）
207

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

livekit/agents のほかの issue

livekit/agents の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。