Dify Community Reports Duplicate Prompt Loading in Agent History, Potentially Increasing API Memory Use for Long Conversations

A technical report posted to Dify on October 22 points to API-side history loading as a performance bottleneck for long conversations. The reporter says the behavior persists in self-hosted version 1.17.1 and in the main branch checked that day, and provides a reproduction script that runs against PostgreSQL. The evidence comes from community testing, so it does not establish that all deployments will show the same results. Issue report

According to the report, organize_agent_history reads the full message rows for an entire conversation, including Message.message, which stores the prompts used to generate each turn. When each prompt includes the preceding conversation, the data for turn n repeats the content of turns 1 through n−1. Loading all rows at once can therefore make the amount of text read grow close to quadratically. However, history reconstruction uses the questions, answers, and agent thought records; it does not need this large prompt field. Technical explanation and code

In a synthetic test with 700 conversation turns, the reporter measured an increase of about 1.36 GB in RSS and a runtime of about 4.2 seconds for a single history build. Selecting only the necessary fields with load_only reduced those figures to 10.3 MB and 0.80 seconds. This was an isolated test; it does not guarantee the same improvement in production or show that the process permanently retains all of the memory. Measurements

The proposed fix has a clear ORM basis: SQLAlchemy documentation explains that load_only lets a query skip unspecified large columns, though accessing them later may trigger a deferred query. raiseload can instead raise an error on unexpected access. This means validation should check not only whether memory use falls, but also that later code paths do not reload the prompt field. SQLAlchemy documentation

For operations teams, the report makes conversation length a useful dimension for capacity testing, alongside measurements of history-build time, process memory, and SQL queries. Engineering validation should also compare reconstructed history before and after reducing the selected fields, and check whether conversations with larger tool records still show bottlenecks. These are validation recommendations inferred from the report. Maintainer confirmation, a merged fix, and a released version are still needed to establish the actual scope of affected deployments.