How do we properly handle token refresh in our custom Flex SDK integration so the session stays alive past the initial TTL?

Ticket

Hi Twilio support team, I hope this finds someone who can help because I've been going around in circles reading the docs and I'm not 100% sure I have the full picture here. We're a mid-size SaaS company and we've been building a custom agent desktop that embeds the @twilio/flex-sdk (not using the stock Flex UI at all, just the SDK directly in our own React app). Things are generally working fine for the first hour or so of an agent's shift, but once that initial token TTL window closes we start seeing some weird behavior and I want to make sure we're handling the refresh flow correctly before we go to production. Here's what we're doing right now, roughly: 1. Agent logs in, our backend mints a Flex user token (JWE) and hands it to the frontend. 2. Frontend calls `const client = await createClient("SDK_TOKEN")` with that token. 3. Everything works great — agents can see tasks, accept voice tasks, messaging tasks come through, etc. 4. After about 3600 seconds (the default TTL I assume) we start seeing error 45775 "Failed to refresh token. Invalid token provided" show up in the console and then SDK calls start failing silently or throwing. So my first question is just: what is the correct sequence of steps to do a clean token refresh so the live client session picks up the new credentials without the agent having to log out and back in? I've seen references to `refreshToken({ refreshToken, ssoProfileSid })` and `validateToken(accountSid, token)` and then `client.updateToken(newToken, newRefreshToken)` but I'm not sure if those are all required in that order, or if some of them are optional, or if there's a timing consideration I'm missing. Right now our frontend is calling our backend to get a new token when we detect the expiry, then we're updating some local state with the new token value, but I don't think we're calling `client.updateToken(...)` at all, which based on some things I read might mean the underlying SDK clients (TaskRouter, Voice, Conversations, Sync) are still holding onto the old stale token even though our app thinks it refreshed. Is that right? Like, do all the connected services automatically pick up the new token if we call `client.updateToken(newToken, newRefreshToken)`, or do we need to do something additional for each one? Second question: is there an event we should be listening for that fires *before* the token actually expires so we can do a proactive refresh rather than reacting to failures? I've seen mention of a `tokenWillExpire` type of event pattern in some Voice SDK docs — is there an equivalent on the Flex SDK client side? Third, somewhat related question: we had one agent yesterday where after the token issue started happening, the session log showed something like `SessionState: setting degraded to true` and they could still see their task queue but inbound voice calls weren't connecting at all. The agent was convinced it was a routing problem and opened a ticket with our internal team, but it sounds to me like that degraded mode is actually a symptom of the Voice SDK client failing to reinitialize after the token problem rather than anything wrong with our TaskRouter config (Workspace WS04f7a2b1c3d8e9f0a1b2c3d4e5f6a7b8, Workflow WWab12cd34ef56ab12cd34ef56ab12cd34 if that matters). Can you confirm that's the right interpretation? And if so, does calling `client.updateToken(...)` with a fresh token recover the Voice client from degraded state automatically, or do we need to fully reinitialize the client? Fourth question and then I'll stop: we noticed error 31207 "JWT token expiration interval is too long" on a few Voice tasks. We have a separate Voice Access Token we're generating for the Voice SDK piece — is that a totally separate token from the Flex user JWE token, and does it have its own TTL constraints independent of the 3600s Flex token? I want to make sure we're not conflating two different token types here. Sorry for the wall of text — I just wanted to give you the full picture rather than go back and forth. We're on Chrome 124 mostly, a few agents on Edge 124. No specific TaskQueue or Worker SIDs are relevant to this since it's a general auth flow question, but happy to provide more if needed. Thanks so much, Daniel