Bug: Removing a favorite overwrites live message state with stale snapshot

[Allaoua9]

Describe the bug
When a user marks a message as a favorite and later removes it from their favorites list using the trash icon, the chat history partially disappears: all the assistant's replies that came after the unfavorited message (up to the next thing the user sent) vanish from the screen. The conversation is not actually lost — refreshing the page brings everything back — but it creates a jarring and confusing experience where the chat appears broken after a simple favorites management action.

To Reproduce

1. Start a conversation and send a user message.
2. Wait for the assistant to fully respond (so it has nested steps/tool calls beneath the user message).
3. Click the star/favorite button on the user message to favorite it.
4. Send another user message and wait for the assistant to respond again (so there are now multiple exchanges).
5. Open the favorites popover (star button in the composer).
6. Click the trash icon next to the favorited message to remove it from favorites.

Screenshots

[dosubot]

This is a duplicate of #2836 [1], which was closed as stale without a fix. A related issue is #2838 [2] (unfavoriting fails with no existing conversation).

The root cause is a data source asymmetry in the backend's message_favorite socket handler [3]:

• Favoriting (favorite=true): uses chat_context.get() — the live, in-memory session state ✅
• Unfavoriting (favorite=false): uses data_layer.get_favorite_steps() — a stale DB snapshot from when the message was first favorited ❌

That stale snapshot (including all mutable fields like output, steps, metadata) is then emitted back to the frontend via update_message [4], where updateMessageById does a shallow spread merge [5] that overwrites the live message content with the outdated version. This is why assistant replies appear to vanish — the message's nested steps/children get replaced with an older snapshot that didn't have them yet. A page refresh restores everything since the data isn't actually lost.

PR #2837 [6] was opened to fix this by updating only the favorite metadata flag rather than replacing the entire message, but it was closed without merging.

The fix should ensure the unfavoriting path either:

1. Uses chat_context.get() (like the favoriting path already does)
2. Uses the message payload the client already sends in the socket event [7]
3. Only persists/emits the metadata.favorite flag delta, not the full StepDict

To reply, just mention @dosu.

---

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

   

[Allaoua9]

this was a duplicate : #2836