I have a previously working AI Agent that has access to some tools, and is hooked up to Supabase as a DB, and using Postgres Chat Memory also linked to Supabase. Now when I try to run the agent I get an error
“- Cannot use a pool after calling end on the pool
Cannot use a pool after calling end on the pool”
What is the error message (if any)?
“- Cannot use a pool after calling end on the pool
Cannot use a pool after calling end on the pool”
Error details
Other info
n8n version
1.74.1 (Self Hosted)
Time
1/15/2025, 4:10:04 PM
Error cause
{}
Error in sub-node ‘Postgres Chat Memory‘
Cannot use a pool after calling end on the pool
Open node
Hi everyone, we’ve just released the fix with version 1.75.1
If anyone can update and test again to see if it is resolved, we’d appreciate the feedback!
I just upgraded my cloud to 1.75.1. Still the same issue where it works for one workflow query, then errors on the second one. “Cannot use a pool after calling end on the pool” on the Postgres Chat Memory node.
In my workflow, I only have a Postgres Chat Memory node. If I restart and ask my chat window a question, it executes and answers as expected. No errors.
However when I open the Postgres Chat Memory node immediately after and click on the connection setting, this error is already there before I even attempt a second question in the chat window: Couldn’t connect with these settings: Connection pool of the database object has been destroyed.
I’ve tried both ports 5432 and 6543 with the same result.
If I wait a few minutes and hit the Retry button (to reconnect) it says: Connection tested successfully.
At that point, I can again run the chat window with a question and it works as well, no errors, unless I run a subsequent chat question immediately after. So strange that it disconnects from the database after a successful query. It’s like there’s a timeout issue of some sort. Sorry for rambling.
There was an explicit call in the Postgres Chat Memory node that terminated the connection pool after every use. We accidentally missed deleting that one line, and now every call to that node terminates the pool, leading to any other postgres node that uses the same credentials also breaking.
We are fixing this here, and will backport the fix as soon as possible.