I am testing LiveKit locally and running into an issue where the agent appears to be connected on the frontend, but nothing is being reflected in my local environment. The LiveKit agent session is also not updating on my end.
I am not sure what is causing this, but the agent does not seem to be connecting to my local setup at all.
This is blocking me from debugging and testing any parameter changes locally.
Could you help me understand:
Why the agent shows as connected on the frontend but is not reflecting anything locally?
Why the LiveKit agent session is not updating in my local environment?
What is the correct way to connect and test the agent locally for debugging?
Are you using the same Lk credentials elsewhere? If the agent server is deployed elsewhere and if you are using the same creds in local, The agent may connect to the deployed one instead of the local one causing such behavior. Just a sanity check you can do
I have changed nothing, and after 2-3 hours, it again connected to my local, and when I close my local server, it connected to the LiveKit cloud. I don’t know what happened.
If you mean you are testing with uv run agent.py dev and also have an agent with the same name deployed to your cloud account, that might be causing confusion
What should I do so that if I am running my agent locally, then the socket should connect from local, while if the local dev server is not running, then it should connect to the cloud.
If you connect your agent to a locally running LiveKit server then you should only get conenctions from the local server. But if you Agent is connect to LiveKit cloud then it will become part of the routing pool for that agent name and new calls will be load-balanced across all available agents with that name.
So @Vishal_Maurya if you look at it practically, There are two agent servers running right, One local and one on cloud. Lets assume you have a FE ui for the agent with for connecting. The usecase is, the agent should first check for local agent server existence and then fallback to deployed server. What i could think of as a solution is use explicit agent dispatch. The key here is, both the severs are using same project creds (an assumption also) then the problem reduces to unique identification of local and remote agent servers while initializing.
If you have a backend for room creation,: Inside both agent servers, give two agents a unique name (local-agent, remote-agent). When connecting, room creation api in backend should first try dispatch with agent-name = local-agent. And if it returns an error, fallback to room creation using remote-agent as agent name.
cc @darryncampbell@CWilson
