## Bug Report: Stale `sessionId` in Feedback Requests After Starting New Chat

[roy-lib]

Bug Report: Stale sessionId in Feedback Requests After Starting New Chat

Summary

When a user clicks "New" to start a fresh chat and then submits feedback on a message in that new chat, the feedback request contains the old session ID from the previous chat instead of the current session ID. This causes the on_feedback callback to fail with "Session not found".

Steps to Reproduce

1. Open a Chainlit app with @cl.on_feedback callback and data persistence enabled
2. Send a message and receive a response (Session A is active)
3. Click "New" to start a new chat (Session B is created, Session A is destroyed)
4. Send a message in the new chat and receive a response
5. Click the feedback button (thumbs up/down) on the new message
6. Observe error: Error in user-provided on_feedback callback: Session not found

Expected Behavior

The feedback request should contain the current session ID (Session B) since the message was created in the current session.

Actual Behavior

The feedback request contains the old session ID (Session A) which no longer exists.

Debug Evidence

Server logs:

New session started (session_id: fefe67e7-7195-4ec1-b2ed-c9fb489e9e62, thread_id: f27c85ce...)  # Session A
New session started (session_id: 8c4291c0-8785-43cc-90ef-01457a2cef05, thread_id: 65e553d8...)  # Session B (after clicking New)
on_message called (session_id: 8c4291c0-8785-43cc-90ef-01457a2cef05, thread_id: 65e553d8...)    # Message sent in Session B
Error in user-provided on_feedback callback: Session not found

Feedback request payload (from browser Network tab):

{
  "feedback": {
    "forId": "8a8f57c8-a6d1-48f1-adc1-819238bc277b",
    "threadId": "65e553d8-a848-4b20-a1e4-17651fa25514",  // ✅ CORRECT (Session B's thread)
    "value": 1,
    "comment": "test"
  },
  "sessionId": "fefe67e7-7195-4ec1-b2ed-c9fb489e9e62"    // ❌ WRONG (Session A's ID - stale!)
}

Note: threadId is correct but sessionId is stale.

Root Cause

The frontend appears to cache the sessionId and doesn't update it when a new chat session is started via the "New" button. The threadId is correctly updated, but sessionId remains stale.

Code Location

In server.py, the feedback endpoint uses the stale sessionId to look up the session:

# server.py ~line 889
session = WebsocketSession.get_by_id(update.sessionId)  # Returns None (stale ID)
init_ws_context(session)  # Fails with "Session not found"
await config.code.on_feedback(update.feedback)  # Never reached

Suggested Fix

Either:

1. Frontend fix: Update the cached sessionId when a new chat is started
2. Backend fix: Use threadId to look up the correct session when sessionId is not found, since threadId is correct in the request

Environment

• Chainlit version: 2.9.3
• Python version: 3.12
• OS: Linux

[dosubot]

Hi @roy-lib! I'm Dosu and I’m helping the chainlit team.

Your analysis is spot on: the stale sessionId in feedback requests after starting a new chat is a frontend state bug—sessionId isn't updated when the "New" button is used, even though threadId is correct. This leads to the backend failing to find the session and the on_feedback callback erroring with "Session not found".

There isn't an existing issue in the repo that tracks this exact bug, but there are several related issues about session and thread management errors, like "Session not found", "Thread {thread_id} not found", and frontend state bugs after thread deletion or navigation (#2709). None of these directly address stale sessionId in feedback, but they highlight similar frontend/backend sync problems.

Your suggested fixes are both valid: updating sessionId in the frontend when starting a new chat, or having the backend fall back to threadId if sessionId is missing or invalid. No documentation or code references specifically address sessionId/threadId management in feedback requests, so investigating the frontend state management for sessionId when starting a new chat is the best next step.

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.

[github-actions]

This issue was closed because it has been inactive for 7 days since being marked as stale.