invoke-ai/InvokeAI · error · TooManySessionsError

call_saved_workflow exceeds remaining queue capacity for chi

Error message

call_saved_workflow exceeds remaining queue capacity for child workflow executions

What it means

TooManySessionsError raised by enqueue_workflow_call_child when the number of already-pending child queue items for the parent's queue_id has reached max_queue_size (the 'pending' count >= configured limit). It protects the queue from unbounded growth when a workflow spawns child executions.

Source

Thrown at invokeai/app/services/session_queue/session_queue_sqlite.py:1208

        if workflow_call_execution is None:
            raise ValueError("Parent queue item is missing active workflow call execution metadata.")

        session_json = child_session.model_dump_json(warnings=False, exclude_none=True)
        field_values_json = json.dumps(field_values, default=to_jsonable_python) if field_values is not None else None
        root_item_id = parent_queue_item.root_item_id or parent_queue_item.item_id

        with self._db.transaction() as cursor:
            cursor.execute(
                """--sql
                SELECT COUNT(*)
                FROM session_queue
                WHERE queue_id = ? AND status = 'pending'
                """,
                (parent_queue_item.queue_id,),
            )
            pending_count = cast(int, cursor.fetchone()[0])
            if pending_count >= self.__invoker.services.configuration.max_queue_size:
                raise TooManySessionsError(
                    "call_saved_workflow exceeds remaining queue capacity for child workflow executions"
                )

            cursor.execute(
                """--sql
                INSERT INTO session_queue (
                    queue_id,
                    session,
                    session_id,
                    batch_id,
                    field_values,
                    priority,
                    workflow,
                    origin,
                    destination,
                    retried_from_item_id,
                    user_id,
                    workflow_call_id,

View on GitHub (pinned to 0b6a024f2f)

Solutions

Raise max_queue_size in the InvokeAI configuration (or via the config service) before enqueueing.
Drain pending items first: wait for workers to move items to 'completed'/'canceled' or explicitly cancel pending items.
Refactor the workflow to enqueue child calls incrementally (enqueue the next only after the previous completes) instead of all at once.
Check for stuck pending items (dead worker) and requeue/cancel them to free capacity.

Example fix

// before
child = queue.enqueue_workflow_call_child(...)  # raises when pending >= max_queue_size
// after
if queue.get_pending_queue_count(parent_queue_item.queue_id) < config.max_queue_size:
    child = queue.enqueue_workflow_call_child(...)
else:
    raise DeferredEnqueue(...)  # retry after workers drain the queue

Defensive patterns

Strategy: try-catch

Validate before calling

pending = queue.get_queue_status(queue_id)  # or COUNT of pending items
if pending >= config.max_queue_size:
    raise RuntimeError('queue full: drain pending items before enqueueing child workflow')

Type guard

def has_child_capacity(queue, queue_id: str, config) -> bool:
    pending = queue.get_queue_status(queue_id).pending  # adapt to actual accessor
    return pending < config.max_queue_size

Try / catch

try:
    child = queue.enqueue_workflow_call_child(...)
except TooManySessionsError:
    wait_until_workers_drain(queue_id)
    child = queue.enqueue_workflow_call_child(...)  # bounded retry

Prevention

Size max_queue_size above your worst-case child-workflow fan-out.
Enqueue children incrementally as predecessors complete.
Monitor pending count and alert before hitting the cap.
Avoid keeping workers stopped while spawning child workflows.

When it happens

Trigger: Calling enqueue_workflow_call_child while COUNT(*) of pending items for the queue >= services.configuration.max_queue_size; enqueueing many child workflow calls in a loop without draining; a stuck/never-executing pending item keeping the count at the cap.

Common situations: max_queue_size set low (or left at a small default) while running fan-out workflows; batch scripts enqueuing dozens of child workflows; environments where workers are stopped so pending items accumulate; version changes that made child workflows count against the same pending budget.

Related errors

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