I get this issue after upgrading from plugin packages from 1 LiveKit Community #ask-ai

I get this issue after upgrading from plugin packa...

average-jordan-45543

03/18/2026, 3:48 PM

I get this issue after upgrading from plugin packages from 1.3.2 -> 1.4.6 and livekit from 1.0.22 -> 1.1.2. It seems to fail to connect 3 times however it eventually does connect. Any ideas? I am running on a local env and connecting from a local client.

Copy code

16:23:28.936 INFO   livekit.agents     received job request  
                                         {"job_id": "AJ_H6tYmwD77vzu", "dispatch_id": "AD_EyfRS5jcEoDj", "room": "5xarak", "room_id": "RM_vq6dtFE5qudP", 
"agent_name": "", "resuming": false, "enable_recording": false}
    16:23:31.457 WARNI… livekit.agents     assignment for job AJ_H6tYmwD77vzu timed out  
                                         {"job_request": "<livekit.agents.job.JobRequest object at 0x11808f380>", "agent_name": ""}
    16:23:31.466 ERROR  livekit.agents     job_request_fnc failed  
                                         {"job_request": "<livekit.agents.job.JobRequest object at 0x11808f380>", "agent_name": ""}
Traceback (most recent call last):
  File "/Users/malteholledig/Freja/freja-agent-python/venv/lib/python3.13/site-packages/livekit/agents/worker.py", line 1279, in _job_request_task
    await self._request_fnc(job_req)
  File "/Users/malteholledig/Freja/freja-agent-python/venv/lib/python3.13/site-packages/livekit/agents/worker.py", line 70, in _default_request_fnc
    await ctx.accept()
  File "/Users/malteholledig/Freja/freja-agent-python/venv/lib/python3.13/site-packages/livekit/agents/job.py", line 809, in accept
    await self._on_accept(accept_arguments)
  File "/Users/malteholledig/Freja/freja-agent-python/venv/lib/python3.13/site-packages/livekit/agents/worker.py", line 1246, in _on_accept
    raise AssignmentTimeoutError() from None
livekit.agents._exceptions.AssignmentTimeoutError

    16:23:35.937 INFO   livekit.agents     received job request  
                                         {"job_id": "AJ_H6tYmwD77vzu", "dispatch_id": "AD_EyfRS5jcEoDj", "room": "5xarak", "room_id": "RM_vq6dtFE5qudP", 
"agent_name": "", "resuming": false, "enable_recording": false}
    16:23:36.436 WARNI… livekit.agents     assignment for job AJ_H6tYmwD77vzu timed out  
                                         {"job_request": "<livekit.agents.job.JobRequest object at 0x1180b11d0>", "agent_name": ""}
    16:23:36.437 ERROR  livekit.agents     job_request_fnc failed  
                                         {"job_request": "<livekit.agents.job.JobRequest object at 0x1180b11d0>", "agent_name": ""}

✅ 1

tall-airline-16756

03/18/2026, 3:48 PM

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

tall-airline-16756

03/18/2026, 3:48 PM

Thanks — I see the logs you pasted and that the error is an

AssignmentTimeoutError

raised during

ctx.accept()

in the agents worker after upgrading package versions. I’ll help you troubleshoot this step-by-step so we can narrow the cause. A few quick checks and clarifying questions first (these will help me recommend targeted fixes): • Are you running the LiveKit server and the agent/worker on the same machine in your local environment? Or is the agent connecting to a separate LiveKit instance? • Which agent implementation are you running (e.g., the example agents from the repo, a custom agent, or a packaged worker)? Do you have any custom logic around

job_request_fnc

on_accept

? • Did you change any timeout-related configuration when upgrading (for example, assignment or request timeouts in agent/worker settings)? • Can you share the agent/worker configuration values for timeouts (if available) or the snippet where

ctx.accept()

is called? • Do you see any corresponding logs on the LiveKit server side at the same timestamps (authentication failures, rejected assignments, or network/connect errors)? Possible causes and things to try now • Assignment timeout behavior: The trace shows the agent attempted to accept the job but hit an assignment timeout. This usually means the server-side assignment window expired before the worker completed whatever acceptance handshake is required. Check any assignment timeout config in the worker and on the server. If default timeout values changed between versions, increasing the worker-side timeout temporarily can confirm this as the cause. • Network/local DNS flakiness: Since you’re local, intermittent connection/connect-resolve delays can make the accept handshake exceed a timeout. Try running the agent and server with increased logging and look for short network/connect errors right before the timeout entries. • Version changes in agent/accept API: Upgrading from livekit-agent/plugin versions may have changed handshake timing or required fields passed during accept. If you added no custom logic, try running an unmodified example agent from the same versions to see if it reproduces. If the example succeeds, it points to a change your code needs to follow. • Race between job request and assignment lifecycle: If multiple internal steps run in

on_accept

job_request_fnc

(e.g., creating room resources or additional API calls), those could be taking too long. Try making `on_accept`/`accept` as lightweight as possible (immediately accept, defer heavier setup) to see whether the timeout stops. • Logging correlation: Add timestamps / more verbose logs around accept start and finish, and on the server side, to confirm whether the assignment is aborted by the server or times out waiting for the worker. The stack shows the exception raised in worker code; server logs will confirm whether the server canceled the assignment first. Short actionable steps to try now 1. Increase the agent assignment/request timeout temporarily (if configurable) to a higher value and re-test. 2. Run an unmodified example agent/worker (matching the new package versions) against your local LiveKit to see whether this is a regression in your code or an environmental issue. 3. Make the

accept

callback minimal (immediately call

ctx.accept()

with no heavy synchronous work) to confirm long setup work isn’t the cause. 4. Enable verbose/debug logs on both worker and server and capture a full request/response timeline around the three attempts that fail then succeed. 5. Check for any version-notes or changelogs between the agent/plugin versions you upgraded that mention changed timeouts, API surface, or required handshake changes. If you can share: • The agent/worker configuration around timeouts (or the code snippet where

ctx.accept()

is called). • Whether running the example agent for the new version reproduces the issue. • Any server-side logs at the same timestamps. I’ll use that to give concrete config changes or code adjustments to fix the repeated timeouts. , with interactive elements

average-jordan-45543

03/20/2026, 8:44 AM

I am not running accept anywhere in my code. The agents I run locally (or for staging/prod, on VS). I am not running the livekit server locally but using cloud here. I use the recommended code for my agents such as

Copy code

async def entrypoint(ctx: JobContext):
    await ctx.connect()
    participant = await ctx.wait_for_participant()

if __name__ == "__main__":
    cli.run_app(
        WorkerOptions(
            entrypoint_fnc=entrypoint,
            prewarm_fnc=prewarm,
        )
    )

tall-airline-16756

03/20/2026, 8:44 AM

Thanks — this is helpful. I can see you’re using the recommended entrypoint pattern and you don’t call

accept()

directly. I’ll focus on what that implies and the most likely causes and fixes given your setup (agents running locally, LiveKit cloud server). What this stack trace means • The worker’s internal logic calls

ctx.accept()

during job handling; your code doesn’t need to call it manually. The exception shows the worker attempted to accept a job but hit an assignment timeout in the worker before the server finished the assignment handshake. • Because you’re using the cloud server, the timeout could be caused by network latency, a change in default timeouts between versions, or something in the agent lifecycle that now takes longer than the allowed assignment window. Most likely causes and immediate checks • Timeout defaults changed between versions: Assignment/request timeout values may have been lowered or the handshake requirements changed. Check whether your local worker version uses a different default timeout than before. • Network latency (local -> cloud): Occasional short delays connecting to the cloud can cause the accept to exceed the timeout. Local environment flakiness (DNS, VPNs, firewall rules) is a common cause. • Work done during agent startup/prewarm/entrypoint: If

prewarm_fnc

entrypoint

(or underlying connect/wait calls) performs extra synchronous/slow work before the worker can complete accept, that can push past the timeout. • Transient server-side processing: The cloud server may briefly delay confirming the assignment (for example under load). Correlating server logs will confirm whether the server canceled the assignment or the worker timed out locally. Concrete steps to narrow and fix this 1. Temporarily increase the agent assignment timeout ◦ Look for a timeout option in

WorkerOptions

or agent config (or environment variable) that controls assignment/request timeout and increase it (e.g., 2–3×). Re-run to see if failed attempts stop. 1. Make

entrypoint

as lightweight as possible for a test ◦ Replace your entrypoint with:

Copy code

async def entrypoint(ctx: JobContext):
         await ctx.connect()
         # immediately wait to ensure accept completes quickly
         participant = await ctx.wait_for_participant()

• You already do this, but also ensure

prewarm_fnc

does not do heavy work. If

prewarm_fnc

does anything network or blocking, disable it for the test. 1. Reproduce with example agent for the same version ◦ Run an unmodified example agent shipped with the same agent/plugin version against your cloud project. If the example succeeds reliably, the issue is likely in your prewarm/entrypoint logic or config. 1. Turn on verbose debug logs on the worker and capture network timing ◦ Increase logging to DEBUG on the agent to log precise timestamps around connect/accept/wait_for_participant and inspect gaps between events. 1. Capture LiveKit server-side logs for the same timestamps ◦ Look for assignment/cancel events or any errors that coincide with the agent timeouts. This will tell you whether the server aborted the assignment or the worker timed out locally waiting for confirmation. 1. Test network latency and DNS resolution to the cloud from your local machine ◦ Run several pings and traceroutes to the LiveKit cloud endpoint and look for sporadic spikes. 1. Try running the agent from a different environment (e.g., a VM in the cloud or another network) to see if the issue is local to your machine/network. Information that will help me give a precise fix • The

WorkerOptions

(or agent config) you pass in, especially any timeout-related fields or environment variables you set. • The

prewarm_fnc

implementation (if it does anything nontrivial). • A short excerpt of debug logs around one full failed-then-successful attempt (both worker logs and any server logs you can share — timestamps are enough). • Whether increasing the worker timeout changes behavior. If you want, start with step 1 (increase timeout) and step 4 (enable debug) and paste the new logs here. I’ll review them and recommend exact config changes or code adjustments. , with interactive elements

average-jordan-45543

03/20/2026, 8:49 AM

Copy code

def prewarm(proc: JobProcess):
    proc.userdata["vad"] = silero.VAD.load()

It has worked fine until I upgraded packages. And I dont see any timeout related params in workeroptions

tall-airline-16756

03/20/2026, 8:49 AM

Thanks — this is very helpful. I can see you call

prewarm

to load the Silero VAD, and you don’t call

accept()

yourself. I’ll focus on that. What’s happening (short) • The worker framework calls

ctx.accept()

internally during job dispatch. The stack shows the worker hit an AssignmentTimeoutError while accepting a job. • The agent framework implements a 10‑second connection/assignment window for job dispatch. Loading large models or doing slow work during process startup/prewarm can push the accept handshake past that window and trigger the timeout. • Since this started after your upgrade, defaults or handshake timing likely tightened and your

prewarm

model load now sometimes takes longer than the assignment window. What to try next (quick experiments — easiest first) 1. Temporarily move the VAD load out of

prewarm

to confirm cause ◦ Change

prewarm

to do nothing, and load the VAD lazily inside

entrypoint

(or on first use):

Copy code

def prewarm(proc: JobProcess):
         pass

     async def entrypoint(ctx: JobContext):
         # lazy-load VAD if not already loaded
         if "vad" not in ctx.proc.userdata:
             ctx.proc.userdata["vad"] = silero.VAD.load()
         await ctx.connect()
         participant = await ctx.wait_for_participant()

• If timeouts disappear, the model load during prewarm is the culprit. 1. Make

prewarm

non-blocking or faster ◦ If you need preloaded weights, try: ▪︎ Loading lighter assets in

prewarm

and deferring heavy initialization until after accept. ▪︎ Using an async or background thread to load weights so

prewarm

returns quickly. 1. Increase assignment timeout temporarily ◦ There’s no timeout field in

WorkerOptions

you currently see, but the framework uses a ~10s dispatch window. If you can find an environment variable or newer option controlling assignment/request timeout in your agent runtime, increase it 2–3× for testing. (If you’re not able to find it, try steps 1–2 first — they’re lower-risk.) 1. Add precise debug logging and test ◦ Enable DEBUG logs and capture timestamps for: ▪︎ process start ▪︎

prewarm

start/finish ▪︎

ctx.connect()

start/finish ▪︎ the assignment/timeout log lines you posted ◦ This will confirm whether the model load overlaps the dispatch window. Why this is the likely cause • The agent lifecycle docs show

prewarm

is intended to load models and heavy assets, but the framework still enforces a short job dispatch/accept window (about 10s). A heavier prewarm that used to fit may now exceed that window after the upgrade. If the timeout persists after trying the above • Share these items and I’ll dig deeper: ◦ A short DEBUG log snippet showing timestamps around process start,

prewarm

load start/end, and the timeout entries. ◦ Whether moving the VAD load into

entrypoint

stops the timeouts. ◦ Any environment variables or config you set for the worker runtime. I know this is disruptive after an upgrade — if you want, start by disabling

prewarm

2 Views

Open in Slack

Previous Next