fix: Editing First Message

[yuhongsun96]

Description

Edge case bug with editing the first message after having refreshed the browser. Usually with the first message sent, the frontend does not know about the root node. After a refresh though, it passes the root node id to the backend as the parent. Which is fine honestly and the logic should handle that. So added a handling for that.

How Has This Been Tested?

Works for sure

Additional Options

• [Optional] Override Linear Check

---

Summary by cubic

Fixes editing the first message after a browser refresh by treating a root-message parent as a root regeneration. If parent_message_id is None or equals the root id, we start from the root and correctly truncate history to prevent misplacement.

^{Written for commit f7bf612. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 1 file

[greptile-apps]

Greptile Overview

Greptile Summary

What Changed

This PR fixes an edge case bug when editing the first message in a chat session after a browser refresh.

The Problem:

• Normally, when editing the first message, the frontend doesn't know about the root node and passes None as parent_message_id
• After a browser refresh, the frontend loads all messages from the backend, including the root message
• When editing the first message post-refresh, the frontend now passes the root message ID instead of None
• The backend wasn't handling this case, causing the edit to fail

The Solution:
Added a check or new_msg_req.parent_message_id == root_message.id to the condition that handles regeneration from root (line 406). This treats passing the root message ID the same as passing None, which is semantically correct since:

• The root message is a SYSTEM type with empty content used only as a structural anchor
• Both None and root_message.id represent "start from the beginning"
• The same behavior (setting parent_message = root_message and truncating history) applies to both cases

Impact:

• Fixes the reported bug without side effects
• No breaking changes to existing functionality
• Maintains backward compatibility (still handles None case)

Confidence Score: 5/5

• Safe to merge - fixes an edge case bug without introducing new issues
• The change correctly handles the edge case where the frontend passes the root message ID as parent after a browser refresh. The logic is sound: treating parent_message_id == root_message.id the same as parent_message_id is None makes semantic sense since both represent starting from the beginning. The root message is a SYSTEM type with empty content that exists only as a structural anchor, so there's no legitimate scenario where responding directly to it would differ from regeneration from root. The fix is minimal, well-targeted, and aligns with existing patterns in the codebase.
• No files require special attention

Important Files Changed

File Analysis

Filename	Score	Overview
backend/onyx/chat/process_message.py	5/5	Adds handling for when frontend sends root message ID as parent after refresh, treating it same as None (regeneration from root)

Sequence Diagram

sequenceDiagram
    participant Frontend
    participant Backend as process_message.py
    participant DB as Database
    
    Note over Frontend: User edits first message<br/>after browser refresh
    
    Frontend->>Backend: sendMessage(parent_message_id=root_message.id)
    Note over Frontend: Frontend now knows<br/>root message ID after refresh
    
    Backend->>DB: get_or_create_root_message()
    DB-->>Backend: root_message (id=X, parent=None)
    
    Backend->>DB: create_chat_history_chain()
    DB-->>Backend: chat_history[]
    
    alt parent_message_id == AUTO_PLACE_AFTER_LATEST_MESSAGE
        Backend->>Backend: parent_message = chat_history[-1] or root_message
    else parent_message_id is None OR parent_message_id == root_message.id
        Note over Backend: NEW: Added root_message.id check<br/>to handle refresh edge case
        Backend->>Backend: parent_message = root_message
        Backend->>Backend: chat_history = [] (truncate)
    else specific parent_message_id
        Backend->>Backend: Find parent in chat_history
        Backend->>Backend: Truncate history to parent
    end
    
    Backend->>DB: create_new_chat_message(parent=parent_message)
    DB-->>Backend: user_message
    
    Backend->>Backend: Continue with LLM loop
    Backend-->>Frontend: Stream response

Loading