Skip to main content
ENES
Bring a workflow →

InferNode does not respond or returns 504

Symptom​

It depends on where you call from:

  • With curl or the SDK, the request to chat/completions takes one or two minutes and ends with HTTP 504 and this body:

    {"error":{"type":"provider_error","code":"provider_timeout","message":"http POST timed out","param":"model.url_completions","request_id":"req_…"}}

  • Right after several failures, the same model returns a different error for a few seconds, with the wait time in the message:

    {"error":{"type":"provider_error","code":"provider_circuit_open","message":"breaker open for http:chat_completions; retry after 30s","request_id":"req_…"}}

  • In OpenCode, the opencode run command ends without writing anything and without an error message; in the interactive interface the turn closes empty.

  • In Studio, agents that use that model respond "El agente tardó demasiado en responder" (The agent took too long to respond) or move to Requiere atención (Needs attention) (The agent does not respond).

If you do not even get the 504 and the connection is refused or times out with no body, it is the second cause below.

Cause​

  • The model does not respond. InferNode received the request, routed it to the model, and the model did not answer in time. The gateway is still alive: that is why it returns a formatted error with a request_id. It usually affects a single model (the one that is down or saturated) while the others respond. When a model fails several times in a row, InferNode stops sending it requests for a few seconds and responds provider_circuit_open with the wait time; once that time passes, it tries again on its own.
  • InferNode is not available. There is no response of any kind, or a 502/503 comes back for any model. It usually coincides with maintenance or an outage of the installation.

How to confirm it​

  1. Test the gateway without a key. If it responds 401 in under a second, InferNode is up and the problem is with the model:

    curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' https://api.<tu-dominio>/infernode/v1/me

  2. Test another model with a minimal request. If Saptiva Turbo responds and the one you were using gives 504, it is the first cause:

    curl -s -m 120 https://api.<tu-dominio>/infernode/v1/chat/completions \
      -H "Authorization: Bearer $INFERNODE_API_KEY" -H 'Content-Type: application/json' \
      -d '{"model":"Saptiva Turbo","messages":[{"role":"user","content":"OK"}],"max_tokens":10}'

  3. If step 1 does not respond or all models fail, it is the second cause. An administrator can check the Dashboard: "Panel inicializándose" (Dashboard initializing) or "Snapshot antiguo" (Stale snapshot) point to the same thing (The Dashboard shows no data).

Solution​

  1. Switch models while it lasts: in OpenCode, /models or -m infernode/turbo; in the SDK, the model field; in a Studio agent, the model selector.
  2. If your code retries, do it with exponential backoff (1 s, 2 s, 4 s) and a maximum of three attempts: a 504 repeated within seconds will not resolve on its own. With provider_circuit_open, wait as long as the message says before the next attempt.
  3. Save the error's request_id and report it to the administrator along with the model and the time. With that, the operator can locate the call (how to report).
  4. If the whole installation does not respond, there is nothing to do on the user side: wait for the administrator's notice.

Next step​

Last updated on