Обратное давление очереди промптов

Обзор

qwen serve теперь применяет обратное давление при приеме промптов для каждой сессии. Лимит по умолчанию составляет 5 ожидающих промптов на сессию. Ожидающий промпт — это промпт, который демон принял через sendPrompt и который еще не завершился, включая промпты, ожидающие в FIFO-очереди сессии, и промпт, выполняющийся в данный момент.

branchSession по-прежнему сериализуется в той же FIFO-очереди для каждой сессии, но это не промпт, и он не потребляет этот лимит промптов.

Семантика

• По умолчанию: maxPendingPromptsPerSession = 5.
• Отключено: 0 или Infinity означает без ограничений.
• Недопустимые значения: отрицательные числа, дроби и NaN отклоняются при создании bridge и в runQwenServe. CLI-флаг принимает неотрицательные целые числа; 0 отключает ограничение.
• Авторитетность: bridge является шлюзом для приема запросов. Учет на стороне SDK — это механизм раннего отказа, а не замена серверному контролю.
• Дедлайн промпта: --prompt-deadline-ms по-прежнему применяется только к уже принятым промптам. Это не ограничение на прием в очередь.

Поведение bridge

SessionEntry отслеживает pendingPromptCount. sendPrompt намеренно не является async, поэтому проверка приема может синхронно выбросить исключение до того, как HTTP-маршруты вернут 202 Accepted.

Процесс приема:

1. Поиск сессии.
2. Отклонение предварительно прерванных сигналов до увеличения счетчика.
3. Если pendingPromptCount >= maxPendingPromptsPerSession, выбрасывается PromptQueueFullError.
4. Увеличение счетчика и постановка промпта в FIFO-очередь.
5. Освобождение слота ровно один раз, когда промис промпта, возвращаемый вызывающему коду, завершается.

Сбои не нарушают работу FIFO, так как конец очереди по-прежнему обрабатывает каждый результат промпта. Исходный вызывающий код всё равно получает ошибку отклонения промпта.

Поведение HTTP

POST /session/:id/prompt перехватывает синхронный PromptQueueFullError до отправки ответа о принятии. Маршрут возвращает:

• Статус: 503
• Заголовок: Retry-After: 5
• Тело: { code: 'prompt_queue_full', error, sessionId, limit, pendingCount }

При сбое приема promptId не возвращается.

/capabilities предоставляет:

{
  "limits": {
    "maxPendingPromptsPerSession": 5
  }
}

Когда ограничение отключено, предоставляемое значение равно null.

Поведение ACP HTTP

Транспорт ACP JSON-RPC преобразует PromptQueueFullError в стабильную структуру ошибки вместо проброса неструктурированной внутренней ошибки:

{
  "data": {
    "errorKind": "prompt_queue_full",
    "sessionId": "...",
    "limit": 5,
    "pendingCount": 5
  }
}

Поведение SDK

DaemonClient имеет локальное резервирование для каждой сессии при вызовах prompt(). Оно резервируется перед отправкой HTTP-запроса и освобождается при:

• устаревшем блокирующем завершении с кодом 200,
• неблокирующем завершении хода с кодом 202,
• turn_error,
• отмене вызывающим кодом,
• завершении SSE,
• сбое fetch или парсинга ответа.

DaemonPendingPromptLimitError означает, что SDK отклонил запрос локально и не отправил запрос промпта.

Опция SDK принимает числовое значение capability напрямую; null отключает локальное ограничение, соответствуя /capabilities.limits.maxPendingPromptsPerSession.

DaemonSessionClient применяет тот же локальный лимит для пути с долгоживущей подпиской. Статические методы createOrAttach, load и resume сохраняют свои существующие позиции параметров; прямое создание может переопределить локальное ограничение.