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

Partite da OpenAIProvider._is_chat_completions_mode e dai due costruttori di payload, verificando come i parametri di providers/base.py arrivano all'SDK. Riproducete il TypeError del protocollo e la richiesta di chat bloccata, quindi verificate che entrambi i percorsi abbiano una deadline e che workflow/graph.py venga salvato senza il suo BOM iniziale.

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.