Threads are bumped up in history (updatedAt is reset) by simply viewing them

[DmitriyAlergant]

Describe the bug

Simply viewing old threads without changing anything leads to bumped up "updatedAt" at a thread level in DB (with official chainlit data layer). While not noticeable initially due to session-level state caching (DB is only written not read), if you refresh the page, the recently viewed threads are shown on top.

On viewing chats, the following calls sequence happens, coming from the socket:

File "chainlit/socket.py", line 223, in disconnect
await persist_user_session(session.thread_id, [session.to](http://session.to/)_persistable())

File "chainlit/socket.py", line 48, in persist_user_session
await data_layer.update_thread(thread_id=thread_id, metadata=metadata)

File "chainlit/data/chainlit_data_layer.py": in update_thread

To Reproduce

1. Start up a chainlit app with persistence, create several threads and give them different names

2. Notice threads order

3. Refresh the page.

4. Click on a couple threads at the bottom

5. Refresh the page

6. Notice these viewed threads are now showing at the top

Expected behavior

Only significant changes should bump up a thread in history, such as:

• Adding messages
• Editing or removing messages

Other operations such as viewing the thread, minor session variables changes, or even renaming the thread, must not be bumping it up in history.

Recommended solution

1. Introduce a new column "contextUpdatedAt" (will need a prisma migration). Selectively pass it over from places where update_thread() is called where there is a chat context changes occur (mainly from context.py and/or chat_context.py, i guess). Use this new column for history sorting.

This way, thread.updatedAt will still track when any changes ocured (including lesser changes) but displayed history order will not be affected unless a substantial chat context change happened.

2. Improve the SQL query in update_thread() to compare new thread state with original. If nothing changed, do not bump up updatedAt timestamp. Note, there is a dependency/overlap with Chainlit Data Layer - preserve metadata in update_thread() #2538 as it is impacting the same piece of code

Additional context

Not sure if the issue might have become more noticeable after timezones bug fix: #2486 (which was rejected, but i have it on my end). There is a chance the timezones mess may have been partially masking the issue - but not fully. That being said, this issue is genuine standalone.

[dosubot]

You're right—viewing a thread currently triggers update_thread, which resets updatedAt even if no meaningful changes occur. This causes threads you've simply viewed to jump to the top of history after a refresh. The root cause is that update_thread always sets updatedAt to datetime.now() on every call, regardless of what changed, and this is confirmed in the code and recent discussions here.

Your suggested solutions—adding a contextUpdatedAt column for sorting and improving the update logic to avoid bumping timestamps unless there are real changes—are both feasible and actively being discussed. PR #2538 is in progress to address this, aiming to preserve thread metadata and avoid unnecessary updates to updatedAt. There’s also overlap with other metadata persistence issues in the same area.

There’s no official documentation on this behavior, so the code and these community threads are the best references. Implementing your recommendations would require a database migration for the new column and frontend changes to sort by contextUpdatedAt instead of updatedAt. If you want to track progress or contribute, keep an eye on the linked PR and issue.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[github-actions]

This issue is stale because it has been open for 14 days with no activity.