How do I properly configure wrap-up activity transitions so workers don't get stuck after reservation timeout?

Ticket

Hey Twilio support team, I'm hoping someone can help me understand if I'm setting something up wrong, or point me to documentation I might be missing, because I've been going in circles on this for a few days now and I'm not sure if it's a configuration gap on my end or something else. Some context: I'm a solo dev maintaining a Flex 2.7.1 deployment, running the standard Flex UI on Chrome 124. We have a fairly simple voice workflow — nothing too exotic. Workers sit in Available, get a reservation, and if they don't accept within our configured timeout window, the reservation times out and the task gets re-evaluated (I can see `task_re_evaluated_reason: reservation_timeout` in the TaskRouter logs, so that part is working as expected). The thing I'm trying to understand is: after a reservation timeout fires, is there a correct way to make sure the worker automatically transitions to a specific Activity? Because what I'm observing is that the worker stays in Available (Activity SID `WA3f8b2c19d4e05a1b67890abcdef1234`) after the timeout, which is actually what we want in most cases — but then sometimes, seemingly at random, the worker gets pushed into an Unavailable state instead (Activity SID `WAc7d92e0f1a2b3456789012345678abcd`), and they have to manually click back to Available to receive tasks again. I initially thought this might be related to our `DequeuePostWorkActivitySid` setting, but the timeouts I'm describing happen before the task is ever accepted, so post-work wrap-up shouldn't even be in play here, right? Like the worker never entered wrap-up, the reservation just timed out. Here's what I've been doing to try to reproduce it consistently: 1. Worker logs in, goes Available — Workspace is `WS4a1b2c3d4e5f6789012345678901abcd` 2. A voice task comes in, reservation `WR9z8y7x6w5v4u3t2s1r0q9p8o7n6m5l` is created 3. Worker does NOT accept — just lets it sit past the timeout threshold 4. TaskRouter logs show the reservation timeout and task re-evaluation, as expected 5. Worker's activity in the TaskRouter Worker page flips to Unavailable — worker SID is `WK2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7` Step 5 is what I don't understand. I haven't set any listener or action that should be pushing the worker to Unavailable on a reservation timeout. I've checked our plugins and we don't have any `reservation.timeout` handler calling `worker.update({ActivitySid: …})` for the Unavailable SID. Our plugin code only touches the `beforeAcceptTask` override for some logging. Is there a built-in Flex or TaskRouter behavior where a reservation timeout automatically moves the worker to a fallback activity? And if so, is there somewhere I configure which activity that should be? I've read through the TaskRouter Worker Activity docs and the Flex wrap-up docs but I can't find anything that explicitly describes this behavior happening on timeout rather than on task completion. I'd also just like to confirm: is this expected to be deterministic? Because the part that really puzzles me is that it doesn't happen every time. Maybe 30-40% of timeout events result in the worker going Unavailable. The other 60-70% the worker stays Available just fine. If this were a config option I'd set, I'd expect it to happen 100% of the time. I've looked at the Status Report download from the Flex UI and I don't see any 45600 or 45601 errors logged around the time these transitions happen, so it doesn't seem like a plugin crash is causing a side effect. Checked `Flex.Monitor.getErrors()` output too and nothing stands out. Any guidance on what's happening here and what knob I should be turning would be really appreciated. Happy to provide more logs or SIDs if needed. Thanks so much