Issue

After an agent clicks Accept on a TaskRouter Task in the Flex UI, the Reservation may not adhere strictly to the expected timeout condition. Instead of emitting reservation.timeout, it may later emit:

• reservation.accepted after the configured reservation timeout has passed, or
• reservation.canceled if TaskRouter cannot complete channel setup.

This behavior is expected. Once an agent attempts to accept a Task, the reservation timeout no longer determines the final outcome.

Product

Twilio Flex

Cause

A Reservation timeout is intended to handle no-response scenarios: the Reservation expires because the Worker did not act on it.

When an agent clicks Accept, or an application accepts the Reservation through the API, TaskRouter has received a response from the Worker. It places the Reservation in an internal onHold state while it sets up the communication channel.

During onHold, the Reservation timeout is paused. For example, TaskRouter may need to:

• Create a Voice Conference and connect the agent and caller.
• Create a Messaging Interaction and add participants to the Conversation.

If the configured timeout passes while setup is in progress, it is treated as a no-op. The timeout does not start again after setup completes.

The final Reservation event depends on whether setup succeeds:

• If setup succeeds, the Reservation transitions to accepted.
• If setup fails, the Reservation transitions to canceled.

What this looks like step by step

1. An agent clicks Accept, or the application calls the Accept action.
2. TaskRouter moves the Reservation into its internal onHold state.
3. TaskRouter sets up the Voice, Chat, or Messaging channel.
4. The Reservation timeout remains paused while setup is in progress.
5. TaskRouter completes the Reservation:
   • reservation.accepted when setup succeeds.
   • reservation.canceled when setup fails.

Setup can take seconds or minutes. Network conditions, browser or VDI performance, and WebRTC or channel-setup latency all affect how long the Reservation remains in onHold.

Additional Information

• onHold is an internal Reservation state and is not exposed as a public Reservation status in the API.

• This behavior applies to both Flex-managed and custom TaskRouter implementations.