Postgres Chat Memory Node Returns Full Table Instead of Limited Context Window

[mdaviesnz]

Bug Description

I am encountering an issue with the Postgres Chat Memory node in n8n where the query to the PostgreSQL database does not respect the "Context Window Length" setting. Despite setting this value to a low number, the query retrieves the full table rather than limiting the amount of historical chat data being returned.
This issue significantly impacts performance when using persistent chat memory, as the full history is unnecessarily loaded.

To Reproduce

1. Configure the Postgres Chat Memory node in a workflow.
2. Set "Context Window Length" to a low number (e.g., 5 or 10).
3. Use a fixed session key to ensure chat memory persists across sessions.
4. Observe the query execution and response time.
5. Check the node output and see that all rows are being returned instead of only the expected limited number.

Expected behavior

The query should retrieve only the specified number of recent chat history entries based on the "Context Window Length" setting, improving performance and reducing response time.

Operating System

Docker Image: docker.n8n.io/n8nio/n8n

n8n Version

1.76.1

Node.js Version

20.18.2

Database

PostgreSQL

Execution mode

main (default)

[Joffcom]

Hey @mdaviesnz,

We have created an internal ticket to look into this which we will be tracking as "GHC-678"

[jeanpaul]

Hi @mdaviesnz -- can you look in the logs of the agent? It should be limited to the number you specify (although it's good to note that an "interaction" is a Human & AI message). The output that is shown in the node itself is indeed the full conversation it seems, but what's being passed to the agent is the correct, limited amount.

[mdaviesnz]

Hi @jeanpaul
When I look in the execution logs on the OpenAI node I can see that it has the full history for that session ID, way more than the 5 that I have it configured to use with the 'Context Window Length' setting in the Postgres Chat Memory node.

Is that the log that you're refering to? I don't think I can see any other logs on the OpenAI API side.

[jeanpaul]

Hi @mdaviesnz, Ah, you are using the OpenAI root node. That's interesting. The memory seems to work correctly in the agent-case, but might not work properly in the OpenAI root node. I'll dig into it some more.

[mdaviesnz]

@jeanpaul Thanks for looking into this! At the moment I'm not able to use the memory as the time for responses goes from 4-5 seconds to more than 1 min.

[damian-duque-gda]

Hi @jeanpaul, I have the same problem. The bug you have fixed is only for the OpenAI node, is it possible to extend it to other nodes, such as AI Agent node?

[jeanpaul]

@damian-duque-gda this should not be an issue with the AI Agent node. The memory entry in the log might show all interactions, but please have a look at the LLM input to see if it sends the entire conversation.

[Dougie777]

This is happening using AI Agent node still in version 114 hooked to postgres memory.

Context length is set to 15 right now.

SELECT
COUNT(*) AS memory_count,
ROUND(SUM(LENGTH(message->>'content')) / 1024.0, 2) AS total_size_kb
FROM n8n_chat_histories
WHERE session_id = '6165006333';

yields:

[
{
"memory_count": "98",
"total_size_kb": "68.36"
}
]

I will have to add code to manually trim the records in the workflow but for sure this BUG still exists.

[BrianMont]

More than an year and the BUG still exist

[Slizzle45]

@jeanpaul @Joffcom this bug still exist