How do I prevent beforeAcceptTask from silently dropping the action on second attempt?

Ticket

Hi Twilio Support, We're running Flex UI 2.7.1 with a custom plugin (let's call it TaskAcceptPlugin) deployed in our current active release. I wanted to check whether there's a recommended pattern for retrying a failed beforeAcceptTask override, because we're seeing some confusing behavior that I'm not sure is expected. Here's the setup: in our plugin we register a beforeAcceptTask handler that makes a short fetch call to our internal API to log some metadata before the task is accepted. Most of the time this works fine. The issue appears when that fetch call fails with a network hiccup — our code catches the error and displays a toast to the agent, then returns without calling the `payload.reject()` callback explicitly (we assumed not calling reject would let the action fall through or allow a retry). What actually happens: 1. Agent receives a reservation (WR4xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, TaskQueue WQbxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx). 2. The agent clicks Accept. 3. The fetch to our API fails; we catch it and show the toast. 4. The AcceptTask action appears to silently swallow — no FlexError is surfaced, the Flex console shows no 45600/45601 code, and the reservation just sits in a pending state on the UI. 5. If the agent clicks Accept a second time, nothing happens at all — the button becomes unresponsive. The reservation eventually times out and the task gets re-evaluated. We verified via `Flex.Monitor.getErrors()` immediately after the second click and it returns an empty array, which is what's confusing us — we would have expected a FlexError to appear there if the action framework was rejecting internally. Repro steps (consistent across Chrome 124 and Edge 124): - Simulate a network failure on the fetch inside beforeAcceptTask by blocking the URL in DevTools. - Click Accept on an inbound voice task. - Observe toast fires, but action appears to hang. - Click Accept again. - Button does nothing; no error logged to Flex Monitor. Worker SID for our test agent: WK3xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. I can also share the configuration SID for the release if that helps — just let me know. So my questions are: 1. Is there a supported way to 'reset' the AcceptTask action so the agent can retry after a beforeAcceptTask failure? 2. Is it expected that a beforeAcceptTask handler that neither resolves cleanly nor calls reject would leave the action framework in a stuck state like this? It's causing us moderate pain because affected agents have to refresh their entire Flex tab to get the reservation back, and by then the reservation has often timed out. We're happy to add explicit reject/resolve handling if that's the fix, but wanted to confirm first whether this stuck-state behavior on the second click is intentional or something we should escalate. Thanks in advance for any guidance.