Skip to content
Point of Contact

SignalR connection failures

“Widget connects, sends a message, but never sees the bot reply”

Cause: the visitor’s SignalR connection bound to userId = sessionId isn’t receiving the broadcast. Usually:

  • A network proxy / corporate firewall stripping WebSocket upgrades. SignalR falls back to long-polling but degrades to higher latency.
  • The widget’s connection dropped silently (sleeping tab, etc.) and the visitor needs to refresh.

Fix: refresh the page. If it persists, check the browser’s network tab — look for failed wss://...signalr.net connections.

”Agent claims a session, visitor sends a message, agent never receives it”

Cause: the agent’s SignalR connection bound to userId = agent.oid isn’t subscribed. Either:

  • The agent hasn’t called /api/agent/negotiate (the Teams app should do this automatically on tab load).
  • The agent’s AAD oid in their token doesn’t match what the broadcast targets (rare — usually means session was claimed by a different account than the current Teams user).

Fix: agent reloads the Teams tab. If the issue persists, check /api/agent/me returns the expected oid.

”All chat connections fail with 401”

Cause: the customer-stack’s SignalR identity settings (AzureSignalRConnectionString__serviceUri / __credential) are missing or wrong. The customer FA’s MI authenticates to SignalR via AAD, NOT via connection string.

Fix: these settings are baked in by the deploy template and can’t drift under the Managed RG’s read-only lock — you also can’t list or edit them yourself (az functionapp config appsettings list is denied for your account). If every chat connection fails with 401, contact support with your stack name; we verify and re-apply the settings with our publisher access.