Asterisk AMI queue caller priority or withdrawal does not take effect

Freeze one disputed caller-control transaction

Preserve node and release, app_queue state, manager account, request and response, ActionID, exact queue and caller channel, Uniqueid, requested priority and Immediate, optional WithdrawInfo, completed before and after QueueStatus sequences, AGENT-class lifecycle events, dialplan trace, QUEUE_WITHDRAW_INFO, queue log, CDR, CEL and reporting timestamps. Redact caller data and credentials.

Classify the earliest mismatch: wrong node, wrong queue, stale channel, denied action, unsupported release, priority not reflected, caller already departed, withdrawal still pending, incomplete snapshot, missing events, unexpected dialplan branch, lost marker, later overwrite or stale reporting.

Prove live channel identity before interpreting success

Match the literal Caller request field to the current QueueEntry channel on the same queue. A caller-ID number, contact-centre record, Linkedid, old channel name or transferred leg is not interchangeable with the live caller channel required by these actions. Compare Uniqueid and timestamps to exclude reuse of a screen row from another call.

If the caller answered, abandoned, timed out or hung up between snapshot and action, the request can no longer prove a priority or withdrawal postcondition. Reproduce only with a controlled caller rather than editing the evidence to fit the intended transaction.

Check priority fields and Immediate without widening the claim

Confirm the request supplied Queue, Caller, Priority and Immediate. The generated action page documents that Immediate: yes reflects the change immediately and changes position, but it publishes neither an omitted default nor a priority range. Compare the installed branch and retain the raw response for rejected or normalized values.

Then use a later completed queue snapshot to compare that caller's priority and position. A different position can also reflect other callers joining or leaving. Even a confirmed priority change does not guarantee the next offer, ring or answer because strategy and member eligibility remain separate.

Allow for withdrawal timing and prove dialplan return

Asterisk 20 upgrade notes say withdrawal signals the call to leave whenever it can and is not guaranteed to make it leave. Do not treat the action response, a brief continued queue appearance or a missing unsolicited event as the final result. Obtain a later complete queue snapshot and follow the exact channel into subsequent dialplan processing.

Read QUEUE_WITHDRAW_INFO only after successful withdrawal and only on the continuing caller channel. An empty value can reflect omitted input, unsuccessful withdrawal, wrong leg or later dialplan handling. Validate any marker before it selects a destination; do not put secrets or untrusted executable dialplan fragments in it.

Reconcile events, logs and reports as separate evidence

The published QueueCallerJoin, QueueCallerLeave and QueueCallerAbandon schemas do not include ActionID. Correlate conservatively by exact queue, channel, Uniqueid and time, while checking manager event class, filters, disconnects and parser continuity. Do not relabel abandonment as withdrawal merely because both remove a caller from a queue.

Queue log, CDR, CEL and external reports describe different histories and may ingest on different schedules. A missing report row does not reverse a proved runtime departure, and a historical row does not establish the caller's current membership or next dialplan instruction.

Repair minimally and retest exact postconditions

Correct only the proved node selection, manager privilege, queue name, live channel lookup, installed-version handling, explicit Immediate, event subscription, snapshot framing, dialplan branch, marker validation or reporting-cache defect. Repeat with one disposable caller and capture each postcondition independently.

Keep request acceptance, changed priority, changed position, queue departure, dialplan continuation, marker value, agent offer, answer, bridge, media and caller outcome as separate results. No PBX, module, queue, manager account, session, caller, channel, dialplan, event stream, log, endpoint, packet, audio or live call was inspected or tested; availability, compatibility, timing, persistence, priority effect, withdrawal, routing and caller outcome remain deployment specific.

A custom marker does not prove caller departure

The QueueLog diagnostic verifies native lifecycle and dialplan evidence separately.