T023

How do I stop plugins from crashing on second task accept?

Ticket

Hi — trying to figure out if we're missing some setup step or if there's a known workaround for this. We have a small contact center (~15 agents) on Flex UI 2.7.1, Chrome 124. We deployed a new plugin version last Tuesday via a release (configuration SID FJxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx). The plugin adds a beforeAcceptTask override to pre-populate some task attributes before the agent clicks Accept. Everything looks fine on the FIRST task each session. But on the second task acceptance in the same browser session, the override throws and the task never accepts. Agents see the reservation sit there until it times out. Console shows: Uncaught (in promise): FlexError [45601] Cannot read properties of undefined (reading 'channel') It's coming from our beforeAcceptTask handler. The weird part: if the agent refreshes the page, the first accept on that fresh session works fine again. Second one fails. Repeat. Repro: 1. Log in as any agent (Worker WKxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, tested across 3 workers) 2. Accept first inbound voice task — works, task picks up correctly 3. Complete task, go through wrap-up 4. Second reservation is created (WRxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) — agent clicks Accept 5. FlexError 45601 thrown, task never accepts, reservation eventually times out We checked Flex.Monitor.getErrors() after step 5 — the error is logged there. We also pulled a Status Report and the error appears consistently referencing our plugin's beforeAcceptTask callback. Is there a recommended pattern for safely reading task channel data inside beforeAcceptTask across multiple task lifecycles in the same session? Wondering if we need to re-initialize something between tasks. Or is there a way to check whether the channel reference is still valid before we try to read it? Happy to share the Status Report if that helps. TaskQueue is WQxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, Workflow WWxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. Thanks

Gold label: bug / high

this pattern is repeatable for any agent logging in, so would have a higher business impact

Results by run

openai · gpt-5.5

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

config

medium

escalate: no

Summary

A custom Flex plugin's beforeAcceptTask override is throwing FlexError 45601 on the second task acceptance in a browser session, preventing that reservation from being accepted until the agent refreshes.

Suggested first response

Thanks for the detailed repro and for checking the Status Report. FlexError 45601 indicates the exception is coming from custom Flex UI/plugin code, and since the stack points to your beforeAcceptTask callback after a recent plugin release, the best immediate mitigation is to roll back to the previous known-good Flex release/configuration if agents are impacted. For debugging, please share the Status Report export and the relevant beforeAcceptTask code; in the meantime, review the handler for any retained task/channel references across task lifecycles and add defensive checks before reading channel data so the override does not throw and block the Accept action.

KB citations

kb-007

576 output tokens · 7.2s · 1 attempt(s)

anthropic · claude-sonnet-4-6

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

bug

high

escalate: no

Summary

A custom Flex plugin's beforeAcceptTask override throws FlexError 45601 on every second task acceptance in the same browser session, causing reservations to time out and blocking agents from accepting tasks.

Suggested first response

Thank you for the detailed report and repro steps. Based on what you've described, FlexError 45601 indicates the error is originating inside your plugin's beforeAcceptTask override rather than the Flex platform itself — specifically, it appears the channel reference on the task object is becoming undefined after the first task lifecycle completes within the same browser session. The most common cause of this pattern is that the task or reservation object captured in the Action override callback is stale or has been torn down after wrap-up, and the plugin is attempting to read properties (such as .channel) from a reference that no longer points to a valid object. We'd recommend the following: 1. Add a defensive null/undefined check for the channel property before reading it in your beforeAcceptTask handler (e.g., if (!task || !task.channel) return early or re-fetch the task from the Flex store). 2. Avoid closing over task or reservation references from a previous lifecycle — always read task data fresh from the payload passed into the override callback on each invocation. 3. If you are storing any task state in module-level or component-level variables between tasks, ensure those are cleared during the task completed or reservation completed event. The Status Report you mentioned would be very helpful — please share it so we can confirm the exact stack trace and rule out any platform-side contribution. Also, since this began after your plugin release last Tuesday (configuration FJxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx), rolling back to the previous known-good Flex Release is available as an immediate workaround to unblock your agents while you investigate the plugin code. Please share the Status Report and your beforeAcceptTask handler code (sanitized as needed) and we'll continue from there.

KB citations

kb-007

466 output tokens · 13.2s · 1 attempt(s)