do we have a configuration for waiting threshold f...
# ask-ai
w
do we have a configuration for waiting threshold for a job to be accepeted by a worker?
t
Thanks for reaching out, Test. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
LiveKit does not provide a direct configuration option for setting a custom waiting threshold for a job to be accepted by a worker. However, the system uses a default assignment timeout of 7.5 seconds. If a worker does not accept the job within this time, it is routed to another available worker. Sources: livekit-agents/livekit/agents/worker.py
w
if no other available worker is present?
t
Hey there! If no other worker is available when a job isn’t accepted within the assignment timeout, the job can’t be assigned. In this case, the system will log an error like
ErrWorkerNotAvailable
, which basically means there’s no one around to take on the job. This error will then be sent back to you.
w
can we have a limit of how many concurrent jobs can be accepted?
t
Hey there! If you want to limit how many jobs a worker can handle at the same time in LiveKit, you can do that using the
load_fnc
and
load_threshold
parameters in
WorkerOptions
. This lets you create a custom load function that checks how busy the worker is and sets a limit for taking on new jobs. For instance, if you'd like to cap a worker at 10 concurrent jobs, here's a simple way to do it:
Copy code
from livekit.agents import Worker, WorkerOptions

def compute_load(worker: Worker) -> float:
    # Returns 1.0 when there are 10 or more active jobs
    return min(len(worker.active_jobs) / 10, 1.0)

opts = WorkerOptions(
    entrypoint_fnc=entrypoint,
    load_fnc=compute_load,
    load_threshold=0.9  # Stops accepting jobs at 90% load (which is 9 jobs)
)
With this setup, the worker will stop picking up new jobs once it hits that threshold. If you want more control, you can also use the
request_fnc
to manually reject jobs based on how many are currently running. Sources: Deployment and scaling | LiveKit Docs | Worker options | LiveKit Docs | livekit-agents/livekit/agents/worker.py
w
can i accpet jobs in burst fashion not all jobs all together?
t
LiveKit is designed to handle jobs in bursts instead of all at once, which helps keep things running smoothly. It smartly spreads out the jobs across workers using its load balancing system, so no single worker gets overwhelmed. Each job gets processed one by one as it comes in, and workers can choose to accept or pass on jobs depending on how busy they are. This way, the system stays flexible and efficient, even when jobs come in bursts.
w
what is the assignment timeout?
t
Just a heads-up: in LiveKit, the assignment timeout is set to 7.5 seconds. This means a worker has that amount of time to accept a job before it times out. If they don’t accept it within that window, the job gets passed on to another available worker. Also, it’s important to know that this timeout is fixed and can’t be changed. Sources: livekit-agents/livekit/agents/voice/agent_session.py | agents/src/worker.ts
w
what is the timeout if no worker is available?
t
Hey there! If there isn’t a worker available to take on a job right away, the system uses a timeout to keep things moving. Usually, this timeout lasts about 7.5 seconds for most setups like Python and Node.js agents, and around 10 seconds if you’re using the Go server. If no one picks up the job within that time, the system will let you know by raising an error — something like
AssignmentTimeoutError
or
ErrAvailabilityTimeout
. When that happens, the system calling this will need to handle the error in a way that makes sense for your workflow. We’re here to help if you need any tips on that! Sources: tests/test_ipc.py | agents/src/worker.ts | pkg/agent/agent_test.go | Deploying to production | LiveKit Docs
w
ASSIGNMENT_TIMEOUT this is after the job is accepted by the worker and server needs to serve?
t
Yes, the
ASSIGNMENT_TIMEOUT
kicks in right after a worker accepts a job. It’s basically the time limit the server has to assign that job to the worker. If the server doesn’t get it done within that window, the worker will raise an
AssignmentTimeoutError
, and then the job might be passed along to another available worker. Hope that clears things up! Sources: livekit-agents/livekit/agents/job.py | README.md
w
ok but i want to know if worker in unavailable how much jobs are queued and till how much time till worker is avilable again?
t
In LiveKit, we don’t queue jobs on workers that aren’t available. Instead, if a worker can’t take a job, it gets quickly rerouted to other available workers after a short assignment timeout (usually about 7.5 seconds). What does this mean for you? • Number of Queued Jobs: 0 (because jobs aren’t waiting around on unavailable workers). • Queue Duration: None (jobs get passed along without any delay). Sources: livekit-agents/livekit/agents/worker.py | Deployment and scaling | LiveKit Docs | Deployment and scaling | LiveKit Docs | Deploying to production | LiveKit Docs
w
ok and if no worker in available to accpet the job till how much time it is in waiting state
t
Hey there! So, when there’s no worker available to take on a job, LiveKit doesn’t specifically say how long the job will stay waiting. But here’s the scoop: the system tries to assign jobs using timeouts—7.5 seconds for workers and 10 seconds for the server. If no workers are around, the job just stays unassigned for a bit, and the system keeps trying based on its job distribution setup. To keep things running smoothly, it’s a good idea to make sure you’ve got enough workers ready by using load balancing and autoscaling. That way, jobs don’t get stuck waiting too long! Sources: livekit-agents/livekit/agents/worker.py | README.md | pkg/agent/client.go | Deploying to production | LiveKit Docs