Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

[Bug]: Action HTTP response-header timeout is selected by a hardcoded engine name, so only Ollama gets the long client

Aberta
  • Algo errado?
#25 1 comentário 1 reação 1 responsável Ver no GitHub

Mantenedores costumam responder em até 5 dias

@ckelseynv já está trabalhando nisso.

Desde 11/9/2026.

  • #93 de @CryptoJones — aberto

Avaliação

Esta issue ainda não foi avaliada.

Descrição

PAIR version or commit

0.91.7 (nvpair-engine-manager 0.17.4, linux/arm64). The code paths below are also present on main.

Affected component

Go services — nvpair-engine-manager

Environment

NVIDIA DGX Spark (GB10, aarch64), Ubuntu 24.04.4 LTS, driver 580.173.02, 10-node PAIR cluster. Reproduced against stock binaries with no local modifications.

Steps to reproduce
  1. Configure an engine other than Ollama.
  2. Issue an engine:action whose HTTP call needs more than 30 seconds to return response headers. The realistic case is a chat action against a large model with a long prompt, where prefill alone can exceed 30s before the first header is written.
  3. Observe the action fail with a transport timeout.
Expected behavior

The per-action timeout should be a property of the action or the manifest rather than of the engine's name, so an engine author can declare that a given action may be slow.

Actual behavior

executor.go defines two clients:

engineResponseHeaderTimeout     = 30 * time.Second
ollamaLoadResponseHeaderTimeout = 10 * time.Minute

and actions.go chooses between them with a literal engine-name comparison:

client := e.client
if engine == "ollama" && action == "run_model" && e.ollamaLoadClient != nil {
    client = e.ollamaLoadClient
}

Every other engine therefore gets 30 seconds for every action, and no manifest field can change it.

By code inspection this is not limited to third-party engines. The shipped lmstudio.json declares a chat action (POST /v1/chat/completions) that uses the 30s client, and the vLLM manifest proposed in #9 declares a chat action as well, so a first-class vLLM engine would inherit the same ceiling.

The failure also presents badly: net/http: timeout awaiting response headers reads as a broken or hung engine rather than a client-side limit.

Sanitized logs or screenshots
action "run_model": Post "http://127.0.0.1:8800/v1/chat/completions":
net/http: timeout awaiting response headers      [30s]

Scope of what I actually observed, to be precise: I hit this with an engine registered through a user manifest in <appdir>/engines/, driving engine-manager over its stdio JSON-RPC. It reproduced consistently while the model was cold and stopped once I pre-warmed the model during load, which is what isolated it to the response-header timeout rather than to the engine itself. I have not reproduced a 30s chat failure on LM Studio directly; that exposure is read from its manifest and the selection logic above.

Suggested fix

An optional per-action timeout_s in the manifest, defaulting to the current 30s, would cover this and would let the Ollama exception move into ollama.json instead of living in Go — removing the engine-name comparison entirely.

Linguagem predominante
Go
Estrelas
1.6k
Forks
266
Merge médio
3d 15h
PRs com merge (30d)
23

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de NVIDIA/Personal-AI-Router

Todas as issues de NVIDIA/Personal-AI-Router

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.