Suppose an n8n call to CometAPI receives response headers after 8 seconds but finishes its body after 45 seconds. Would setting HTTP Request Timeout to 10000 necessarily reject it at 10 seconds?
Not on the basis of that setting’s documented meaning. These are hypothetical timings, not a measured CometAPI result. n8n’s HTTP Request documentation defines Timeout as the wait for response headers and the start of the response body, in milliseconds. It says the node aborts requests exceeding that initial-response limit. That is not documentation of a whole-generation deadline—and it is not proof that no other timeout can interrupt the request.
Keep the CometAPI integration boundary explicit
The official CometAPI n8n guide supplies the OpenAI-compatible base URL https://api.cometapi.com/v1, tells users to use exact model IDs from its documentation, and notes that certain reasoning-heavy models may take longer to process.
Its main setup walkthrough uses an OpenAI node. The procedure below is an HTTP Request adaptation, not a claim about that OpenAI node’s timeout semantics or the optional community CometAPI node.
Before troubleshooting, have a working CometAPI credential stored in n8n, the documented operation path and request body for the chosen task, and its exact model ID. The /v1 URL is a base, not a complete generation request. Preserve that gateway and model ID during the first diagnostic run; otherwise a route or model change makes the timing comparison harder to interpret. Do not copy secrets into diagnostic exports.
Measure two boundaries before changing the limit
- Record the request configuration. Note the n8n version, node type, operation, exact model ID, streaming choice if applicable, and Timeout value. Keep the same small test input across comparisons.
- Separate initial response from completion. Measure elapsed time to response headers/body start and elapsed time to the complete body with timing-capable instrumentation in a controlled test. If the workflow only exposes total duration, mark initial-response timing as unknown rather than deriving it from the final output.
- Collect response context safely. n8n documents an Include Response Headers and Status option that returns those alongside the body. This can help distinguish a returned error from a missing response, but it is not documented as a header-arrival clock. Retain only sanitized diagnostic fields.
- Change the boundary that actually failed. If the initial response exceeds your configured allowance, consider a larger initial-response limit that fits the application. If the response starts within that allowance but completes too late, investigate a separate workflow/application completion budget and test its enforcement. Raising the HTTP Request Timeout alone does not establish that budget.
For this CometAPI adaptation, the vendor’s warning about reasoning-heavy calls is a reason to measure, not evidence that a particular model will exceed a particular threshold. Keep the gateway and model fixed while identifying the failed boundary; evaluate a different model only as a separate quality-and-latency experiment.
What this does not establish
These sources do not give a universal safe timeout, guarantee streaming behavior, or prove that a client abort cancels upstream generation. A local timeout also does not establish whether the remote request finished. Preserve the uncertain outcome and investigate before blindly resubmitting it.
The practical decision is to keep initial-response allowance and full-completion acceptance separate. Apply the documented HTTP Request setting to the first, and verify the second in the actual CometAPI workflow rather than treating one millisecond field as an end-to-end guarantee.