invoke-ai/InvokeAI · error · HTTPException

Unexpected error while getting next queue item: {e}

Error message

Unexpected error while getting next queue item: {e}

What it means

Catch-all 500 for get_next_queue_item: exceptions from session_queue.get_next() (or sanitization of the pending item) are wrapped as HTTP 500. Returns the next pending queue item or null when nothing is pending.

Source

Thrown at invokeai/app/api/routers/session_queue.py:506

@session_queue_router.get(
    "/{queue_id}/next",
    operation_id="get_next_queue_item",
    responses={
        200: {"model": Optional[SessionQueueItem]},
    },
)
def get_next_queue_item(
    current_user: CurrentUserOrDefault,
    queue_id: str = Path(description="The queue id to perform this operation on"),
) -> Optional[SessionQueueItem]:
    """Gets the next queue item, without executing it"""
    try:
        item = ApiDependencies.invoker.services.session_queue.get_next(queue_id)
        if item is not None:
            item = sanitize_queue_item_for_user(item, current_user.user_id, current_user.is_admin)
        return item
    except Exception as e:
        raise HTTPException(status_code=500, detail=f"Unexpected error while getting next queue item: {e}")


@session_queue_router.get(
    "/{queue_id}/status",
    operation_id="get_queue_status",
    responses={
        200: {"model": SessionQueueAndProcessorStatus},
    },
)
def get_queue_status(
    current_user: CurrentUserOrDefault,
    queue_id: str = Path(description="The queue id to perform this operation on"),
) -> SessionQueueAndProcessorStatus:
    """Gets the status of the session queue. Returns global counts; every user additionally gets
    their own pending/in_progress counts (so the UI can show an X/Y badge and scope personal UI
    like the progress bar to the user's own activity). Non-admin users cannot see the current
    item's identifiers unless they own it."""
    try:

View on GitHub (pinned to 0b6a024f2f)

Solutions

  1. Inspect the {e} detail and server traceback for the root cause.
  2. Verify queue_id and database health before increasing poll rates.
  3. Back off polling on 500s instead of retrying in a tight loop (this worsens DB contention).
  4. Repair/upgrade InvokeAI if item rows are corrupted or the service is misbehaving.

Example fix

// before: tight polling loop
while True: requests.get(f"{base}/api/v1/queue/{queue_id}/next")
// after: back off on failure
resp = requests.get(f"{base}/api/v1/queue/{queue_id}/next")
if resp.status_code == 500:
    time.sleep(min(backoff *= 2, 60))
else:
    backoff = 1
Defensive patterns

Strategy: retry

Validate before calling

const status = await fetch(`${base}/api/v1/queue/${queueId}/status`).then(r => r.json());
if (status.pending === 0) return null; // skip next-item poll entirely

Type guard

function isPendingQueueItem(v) {
  return v !== null && typeof v === 'object' && 'item_id' in v && v.status === 'pending';
}

Try / catch

async function pollNext() {
  const r = await fetch(`${base}/api/v1/queue/${queueId}/next`);
  if (r.status === 500) {
    await sleep(Math.min((backoff *= 2), 60000));
    return pollNext();
  }
  backoff = 1000;
  return r.json(); // null when nothing pending
}

Prevention

When it happens

Trigger: GET /api/v1/queue/{queue_id}/next when the service call raises (DB failure, unknown queue) or sanitize_queue_item_for_user fails on malformed pending item data.

Common situations: DB lock/down during heavy queue churn; queue_id typo; corrupted pending item row; aggressive polling scripts hammering a failing DB.

Related errors


AI-assisted analysis of invoke-ai/InvokeAI@0b6a024f2f (2026-08-29). Data as JSON: /api/errors/73a5b634da9c4a06. Report an issue: GitHub.