Question: 5s polling of /settings/regions while connected — intentional? Ways to reduce frequency?

[roger-marquardt-trilogy]

Question

Is the 5-second auto-refetch of GET /settings/regions while a room stays connected intentional? For long-lived SPA sessions we see ~12 requests/minute to https://{project}.livekit.cloud/settings/regions even when the user is idle (no mic, no chat).

We want to confirm expected behavior and whether there is a supported way to reduce polling frequency without disconnecting the room.

Environment

• SDK: livekit-client@2.19.0
• Hosting: LiveKit Cloud (*.livekit.cloud)
• Client: Next.js 15 SPA; room stays connected across in-app navigation (session persistence)

Observed behavior

1. On Room.connect() to a Cloud URL, the client fetches /settings/regions (via RegionUrlProvider).
2. While connected, the SDK schedules another fetch every maxAgeInMs.
3. When the response has no Cache-Control: max-age, DEFAULT_MAX_AGE_MS (5_000) applies.
4. Result: ~1 GET every 5 seconds for the entire time the room is connected (~12/min), visible in browser devtools.

This matches RegionUrlProvider in v2.19 (DEFAULT_MAX_AGE_MS = 5_000, scheduleRefetch loop, notifyConnected / notifyDisconnected + STOP_REFETCH_DELAY_MS).

Use case

We hoist a single LiveKit room into our authenticated app shell so customers can navigate (Home → Contracts → Renewals) without tearing down the agent session. The room may stay connected for many minutes while the user browses non-voice pages. Region metadata seems unlikely to need refreshing every 5 seconds during an idle connected session.

Questions

1. Is 5s the intended refresh interval for connected clients when Cloud omits Cache-Control? Or is Cloud expected to return a longer max-age and the 5s default is only a fallback for misconfigured responses?
2. Should LiveKit Cloud add Cache-Control: max-age=… on /settings/regions (e.g. minutes/hours) so clients poll less aggressively?
3. Is there a public SDK option to tune region-settings cache TTL or disable background refetch while connected (we did not find one on Room / RoomConnectOptions)?
4. Reconnect/failover: Does the 5s poll materially improve failover vs. refreshing only on connect/reconnect? Would a longer interval (e.g. 5–15 min) be acceptable for most production apps?

What we are not asking for

• We understand region selection is required for Cloud edge routing at connect time.
• We are not seeing connection failures — only frequent background HTTP traffic.

Possible directions (for discussion)

• Increase DEFAULT_MAX_AGE_MS when server omits cache headers
• Have Cloud return meaningful Cache-Control on /settings/regions
• Expose a client-configurable region settings TTL
• Stop background refetch while connected once a region is selected, and only refetch on reconnect / explicit failover

Happy to provide HAR captures or a minimal repro if useful.

[lukasIO]

Hi!

This behaviour is intentional.

Region metadata seems unlikely to need refreshing every 5 seconds during an idle connected session.

even for idle sessions the signalling connection might go away at any time due to network disruptions and an up to date region table minimises reconnection time. The 5s interval is quite frequent, agreed, but the actual networking impact should be negligible.

I'll close this as it is expected behaviour. If you see any issues with the mechanism feel free to reopen