Unhandled error type aborted when using Agent

[dreamorosi]

As per title, I'm using an agent with a few tools and whenever the agent calls one of its tools I get an error:

error: [api/server/controllers/agents/client.js #sendCompletion] Unhandled error type aborted
error: [handleAbortError] AI response error; aborting request: aborted

At least for me, this only happens for certain models like us.amazon.nova-pro-v1:0 and us.amazon.nova-lite-v1:0. Besides from this specific feature, the models work fine in LibreChat, so I'm inclined to think it's an agent specific issue.

Likewise, the same exact agent with the same set of tools works fine with other models (i.e. us.anthropic.claude-3-5-sonnet-20241022-v2:0), so I would also exclude agent or tool-specific issues.

Based on the model's documentation, these models should support tool usage, so I'm unsure about what's happening.

With that said, since the error is quite opaque/non descriptive I'm unsure how to troubleshoot it further and would appreciate some help. These models are quite cheaper, so I'd like to use them in place of the Anthropic ones for this type of task.

[danny-avila]

Some LLMs are better with tools than others, or it could be a context issue. Are you sure there aren't any more logs for this?

Log locations:

• Docker: Project root directory ./logs
• npm: ./api/logs

There are two types of logs that can help diagnose the issue:

• debug logs (debug-YYYY-MM-DD.log)
• error logs (error-YYYY-MM-DD.log)

Error logs contain exact stack traces and are especially helpful, but both can provide valuable information.
Please only include the relevant portions of logs that correspond to when you reproduced the error.

[dreamorosi]

Thanks for the answer, the logs in the error logs are also quite opaque (at least to me) which is why I opened the discussion.

Below is the debug log - I only redacted the content in the payload:

2025-02-17T16:15:31.472Z debug: [api/server/controllers/agents/client.js] chatCompletion
{
  baseURL: undefined,
  // 1 payload(s)
  payload: [{"role":"user","content":"[REDACTED]"}],
}
2025-02-17T16:15:31.488Z debug: [saveConvo] api/app/clients/BaseClient.js - saveMessageToDatabase #saveConvo
2025-02-17T16:15:33.771Z error: [api/server/controllers/agents/client.js #sendCompletion] Unhandled error type aborted
2025-02-17T16:15:33.771Z error: [handleAbortError] AI response error; aborting request: aborted
2025-02-17T16:15:33.777Z debug: [AgentController] Request closed

this is the corresponding error log:

{"code":"ECONNRESET","level":"error","message":"[api/server/controllers/agents/client.js #sendCompletion] Unhandled error type aborted","pregelTaskId":"23feeb27-cd7e-51d5-8ca5-ba403949d406","stack":"Error: aborted\n    at TLSSocket.socketCloseListener (node:_http_client:464:19)\n    at TLSSocket.emit (node:events:530:35)\n    at node:net:343:12\n    at TCP.done (node:_tls_wrap:648:7)\n    at TCP.callbackTrampoline (node:internal/async_hooks:130:17)"}
{"code":"ECONNRESET","level":"error","message":"[handleAbortError] AI response error; aborting request: aborted","pregelTaskId":"23feeb27-cd7e-51d5-8ca5-ba403949d406","stack":"Error: aborted\n    at TLSSocket.socketCloseListener (node:_http_client:464:19)\n    at TLSSocket.emit (node:events:530:35)\n    at node:net:343:12\n    at TCP.done (node:_tls_wrap:648:7)\n    at TCP.callbackTrampoline (node:internal/async_hooks:130:17)"}

[whalygood]

We are also experiencing something similar using gpt-4o or gpt-4o-mini through Azure OpenAI with Agents.
The Agent is using the File Search capability through the RAG API and the Google Search plugin, but only the File Search action was invoked for this particular chat. @danny-avila

The error displayed in the UI is:
"Error connecting to server, try refreshing the page."

The log from the LibreChat-API Docker container is:

{"entity_id":"agent_WrJwRJWVsrX1ABOdavbBN","file_id":"0c922404-2015-4f5a-b10e-60447c76778d","k":5,"level":"debug","message":"[file_search] RAG API /query body","query":"REDACTED","timestamp":"2025-02-27T17:01:06.629Z"}
{"level":"debug","message":"[AgentController] Request closed","timestamp":"2025-02-27T17:02:09.042Z"}
{"level":"debug","message":"[AgentController] Request aborted on close","timestamp":"2025-02-27T17:02:09.042Z"}
{"level":"warn","message":"[api/server/controllers/agents/client.js #sendCompletion] Operation aborted Aborted","stack":"Error: Aborted\n    at EventTarget.listener (/[app/node_modules/@langchain/core/dist/utils/signal.cjs:20:24](http://app/node_modules/@langchain/core/dist/utils/signal.cjs:20:24))\n    at [nodejs.internal.kHybridDispatch] (node:internal/event_target:820:20)\n    at EventTarget.dispatchEvent (node:internal/event_target:755:26)\n  ...","timestamp":"2025-02-27T17:02:09.043Z"}
{"level":"debug","message":"[saveConvo] api/app/clients/BaseClient.js - saveMessageToDatabase #saveConvo","timestamp":"2025-02-27T17:02:09.048Z"}

The log from debug-2025-02-27.log in the logs directory is:

2025-02-27T17:02:09.042Z debug: [AgentController] Request closed
2025-02-27T17:02:09.042Z debug: [AgentController] Request aborted on close
2025-02-27T17:02:09.043Z warn: [api/server/controllers/agents/client.js #sendCompletion] Operation aborted Aborted
2025-02-27T17:02:09.048Z debug: [saveConvo] api/app/clients/BaseClient.js - saveMessageToDatabase #saveConvo

Edit: It looks like turning off "Resend files" for the model helps avoid the above error.
There is still an issue on the second "user" turn of the chat though

[danny-avila]

It seems to me these could be connection issues somewhere along the pipeline. with tool usage, the amount of integrations being used at once grows. If there was an error in the codebase, it would show up properly in the logs, but an Abort error, especially an unexpected one, could mean something is timing out or severing the connection

[dreamorosi]

That's fair, although I think it would be more helpful to get the actual error/stack trace show up in the logs rather than an opaque Unhandled error type aborted

[danny-avila]

You're right, looks like it's being re-thrown before the error is properly logged, will fix that

[whalygood]

Is it possible that this is something to do with a timeout on the RAG API, since the File Search capability relies on that?
I've tried disabling all other tools such as Google Search and am still running into this.
Is there an environment variable which we can pass to the RAG API container to increase the time out?

[zeemy23]

+1 we're seeing this with an agent that has 260 uploaded small files, less than 2MB altogether.