Ninja Mountain symbolNinjaMountain

T027

How do we prevent beforeAcceptTask from occasionally blocking agents?

Ticket

Hi, We're running Flex UI 2.7.1 across a large agent population (Chrome 124). We added a beforeAcceptTask override in our plugin a few weeks ago to do some pre-acceptance attribute stamping before a task is accepted. General question: is there a recommended pattern for invoking a follow-up action inside a beforeAcceptTask override? We're currently calling Flex.Actions.invokeAction inside the override and returning the result. The reason we're asking: intermittently, maybe 5-10 times a day out of hundreds of acceptances, the task acceptance just silently stops. The agent sees the reservation ring, nothing happens when they click Accept, and the task eventually times out and goes back into the queue. It doesn't happen to any specific agent or queue. No visible error in the UI on the agent's screen, and it's not consistent enough that we can reliably reproduce it on demand. We noticed if we temporarily remove our beforeAcceptTask override entirely, we stop seeing the stuck acceptances. So we suspect something about how we have it wired up is occasionally causing the action chain to not complete, but we're not sure what the correct way to structure this is. Workspace is WS redacted, TaskQueue in question is WQ redacted. Happy to pull a Status Report from an affected agent session if that helps. What's the right approach here?

Gold label: config / medium

the fact that it is intermittent points to a config setting needing to be increased

Results by run

openai · gpt-5.5

2026-10-04 17:23 UTC · prompt ef0017a

config (correct)
medium (correct)
escalate: no

Summary

A custom Flex plugin beforeAcceptTask override appears to intermittently prevent the AcceptTask action chain from completing, causing reservations to time out and return to queue.

Suggested first response

Thanks for the details. Since removing the beforeAcceptTask override stops the issue, this most likely points to the custom plugin action handler rather than TaskRouter itself. In a beforeAcceptTask listener, avoid invoking and returning another Flex.Actions.invokeAction result as part of the same acceptance path unless you are certain it always resolves quickly and cannot re-enter or block the action chain. The safer pattern is to do only the required pre-accept async work, wrap it in try/catch, ensure the promise always resolves or explicitly aborts, and move any non-blocking follow-up work to afterAcceptTask where possible. Please send a Status Report from an affected session plus any Console/Network errors around the failed acceptance so we can confirm whether the handler is throwing, rejecting, or hanging; if needed, also compare against the previous known-good plugin release.

KB citations

kb-007, kb-008

722 output tokens · 8.8s · 1 attempt(s)

anthropic · claude-sonnet-4-6

2026-10-04 17:20 UTC · prompt ef0017a

bug (wrong)
medium (correct)
escalate: no

Summary

A custom beforeAcceptTask Action override in the customer's Flex plugin intermittently causes task acceptance to silently fail, resulting in reservation timeouts for a small percentage of acceptances.

Suggested first response

Thank you for the detailed write-up — this is very helpful context. The pattern you're describing (acceptance silently stopping only when the beforeAcceptTask override is active, with no visible UI error) is consistent with an Action chain not resolving or rejecting cleanly inside the override, which causes Flex to stall rather than proceed or surface an error. The key thing to be aware of with beforeAcceptTask (and Action overrides generally) is that Flex expects the override function to either resolve or reject its promise reliably every time. If the promise returned by your override hangs — for example, because invokeAction itself returns a promise that doesn't settle under certain race or timing conditions — Flex will not proceed with the acceptance, and the reservation will eventually time out back to the queue, which matches what you're seeing. A few things to check and try: 1. Wrap your invokeAction call in a try/catch (or .catch()) and ensure any rejection is explicitly re-thrown or handled — an unhandled rejection inside an override can silently swallow the action chain. 2. Add a timeout/fallback so that if the inner invokeAction call does not settle within a reasonable window (e.g. 5 seconds), you either reject explicitly or allow the action to proceed without the attribute stamping, rather than hanging indefinitely. 3. Avoid calling Flex.Actions.invokeAction('AcceptTask') or similar nested invocations inside beforeAcceptTask if that is what you are doing — invoking the same action recursively inside its own before-hook is a known source of infinite loops or deadlocks in the Flex action framework. The recommended pattern for attribute stamping before acceptance is to perform your async work (e.g. a TaskRouter Task attribute update via the REST API or a Twilio Function) and then resolve the override promise, letting Flex complete the original AcceptTask action naturally. 4. Add console logging at the entry and exit of your override (including the catch path) so you can correlate a Status Report from an affected session with exactly where the override stalled. Could you share a Status Report export from an affected agent session (captured immediately after a stuck acceptance)? That will show us whether a 45601 error or an unhandled promise rejection is being recorded at the time of the failure, and will help us pinpoint whether this is purely in the plugin layer or if there is any underlying platform signal. Workspace SID and TaskQueue SID noted — we may also want to pull the specific Reservation SID for a failed acceptance to check the TaskRouter event stream on our end.

KB citations

kb-007, kb-008

659 output tokens · 17.8s · 1 attempt(s)