Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Provider layer: protocol raises TypeError, and the chat path has no request timeout

Abierto
  • ¿Algo no está bien?
#674 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@zhengguangzhuo ya está trabajando en esto.

Desde el 29/9/2026.

  • #683 de @zhengguangzhuo — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
api, backend

Línea de trabajo

Comience en OpenAIProvider._is_chat_completions_mode y en los dos constructores de payload, comprobando cómo los parámetros de providers/base.py llegan al SDK. Reproduzca el TypeError del protocolo y la solicitud de chat bloqueada, y después verifique que ambas rutas tienen un deadline y que workflow/graph.py se guarda sin su BOM inicial.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Hi, while reading through the provider layer, we found two issues and one small file note. They're all in the same part of the code, so we're putting them together. If any of it is deliberate, or if we're misreading how the pieces fit, please tell us and feel free to close it.

1. Setting protocol raises TypeError

OpenAIProvider._is_chat_completions_mode reads the key from the provider params, so it reads as the intended way to pick between the two APIs:

def _is_chat_completions_mode(self, client) -> bool:
    protocol = self.params.get("protocol")
    if protocol == "chat":
        return True
    if protocol == "responses":
        return False
    # Default to Responses API only if it exists on the client
    return not hasattr(client, "responses")

But neither payload builder removes that key before handing the rest to the SDK — both end the same way:

        # Pass any remaining kwargs directly
        payload.update(params)
        return payload

params comes straight from the node config (self.params = config.params in providers/base.py), and the only keys popped along the way are max_tokens, max_output_tokens, temperature, tools, tool_choice and timeout. So protocol reaches the SDK as an unknown keyword argument:

TypeError: Completions.create() got an unexpected keyword argument 'protocol'

What we saw when we set protocol: chat on a node: the node caught the error and returned it as its output, so the workflow "completed" with

Error calling model gpt-4o: Completions.create() got an unexpected keyword argument 'protocol'

instead of an answer. protocol: responses behaves the same way, because _build_request_payload ends with the same payload.update(params) line — so today the parameter can't be used in either direction.

Possible fix: treat protocol like the other transport-level keys — params.pop("protocol", None) in both builders, or read it from the config object instead of from params.

2. The chat-completions path has no request timeout

The two API paths behave differently when the endpoint stops answering. The Responses payload builder sets a timeout:

# _build_request_payload
payload: Dict[str, Any] = {
    ...
    "temperature": params.pop("temperature", 0.7),
    "timeout": params.pop("timeout", 300),  # 5 min
}

The chat-completions builder (_build_chat_payload) sets none, and the client is created without one either (OpenAI(api_key=..., base_url=...)). So on that path the SDK defaults apply — on the version we looked at (openai 1.109.1):

Timeout(connect=5.0, read=600, write=600, pool=600)

An endpoint that is down fails fast (the 5 s connect timeout), which is fine. The case that isn't covered is an endpoint that accepts the connection and then goes quiet (a hung upstream, an overloaded gateway): the node then waits out the 600 s read timeout with no deadline of its own. That path isn't exotic — it's the one in use with a gateway or self-hosted endpoint, and it's also what the provider falls back to when the Responses attempt fails.

We noticed it with a stalled endpoint: the run sat there with no error and no output until we stopped it — the 300 s timeout that would have ended it only applies to the Responses path.

Possible fix: give _build_chat_payload the same "timeout": params.pop("timeout", 300) line (plus a client-level default), so both paths behave the same. Whether the default should be 300 s or something shorter is your call — the point is having a deadline on both paths.

3. Minor: workflow/graph.py starts with a UTF-8 BOM

The file's first three bytes are EF BB BF. Python's import machinery strips a leading BOM, so nothing in the runtime is affected — but tools that read the file as plain UTF-8 fail on line 1 with invalid character in identifier. Saving it as UTF-8 without BOM would fix that.

Happy to test a patch if you'd like one.

Lenguaje dominante
Python
Estrellas
34.5k
Forks
4.3k
Sin PR fusionados en 30 d

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OpenBMB/ChatDev

Todos los issues de OpenBMB/ChatDev

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.