Fix: "no fronter found" when forcing a fronter leave-3-way

You call force_fronter_leave_3way expecting the fronter to drop off, and instead you get back no fronter found. The call keeps going with the fronter still in it. This error is not a bug; it means the function searched and could not match a second agent session to the call you pointed it at. Once you understand what it searches for, the fix is usually quick.

What the function is looking for

The function takes a named agent_user, the Closer, and refuses to act on that named user. It then hunts for the oldest other user who is on a call with the same Lead id. That other user is the Fronter. If no such second session exists, there is nobody to send the leave command to, and you get no fronter found. So the error is really saying: I could not see a second agent on this lead.

Cause, check, fix

flowchart TD
  A[no fronter found] --> B{Is named agent logged in and on a call}
  B -->|No| C[Fix login or call state first]
  B -->|Yes| D{Is a second agent on the same lead}
  D -->|No| E[Fronter already left or never joined]
  D -->|Yes| F{Is fronter on a different cluster}
  F -->|Yes| G[Use LOCAL_AND_CCC or CCC_REMOTE]
  F -->|No| H[Confirm both sessions share the lead id]
  H --> I[Re-run with LOCAL_ONLY]

Start at the top. The named agent must be logged in and actually on a phone call; if not, you would see a different error, but it is worth confirming first. Next, check whether a second agent is genuinely on the same lead. The most common cause of this error is timing: the fronter already left the 3-way a moment earlier, so there is no second session left to push out. In that case the error is harmless, the handoff already happened, and you can ignore it. Remember the function skips the named agent on purpose and only counts other sessions, so a closer sitting alone with the customer will always come back empty regardless of which value you pass.

The second common cause is a split deployment. If you ran the function with LOCAL_ONLY but the fronter is on a different cluster, the local search finds nothing. Switch the value to LOCAL_AND_CCC so it checks the local cluster and then the remote CCC, or use CCC_REMOTE with the lead_id when the closer is not on this cluster at all. Picking the wrong search scope is the single most preventable version of this error on multi-server floors.

Build it so you never see it

If you are scripting this through the Agent API, treat no fronter found as an expected outcome and not a crash. Log it, confirm the call state, and move on. Do not retry in a tight loop, because if the fronter already left, the answer will never change and you would just burn requests. The cleanest pattern is to only fire the force after you have confirmed two sessions are on the lead, which sidesteps the error entirely. On multi-server floors, store which cluster the fronter is on with the call record so you always pick the right value the first time instead of guessing and falling through to an empty search.

For how the underlying drop works when it succeeds, read force_fronter_leave_3way, and for the whole fronter-to-closer chain see the transfers and closers guide.

If chasing these handoff edge cases is eating your day, a managed dialer takes the tuning off your plate. Our pricing shows what that looks like.