fix: fork session

[angiejones]

Summary

The Fork Session feature was not working if the message was not edited.

In UserMessage.tsx, the handleSave function had this flow:

const handleSave = (editType: 'fork' | 'edit' = 'fork') => {
  setIsEditing(false);                              // ← always closes the textbox
  if (editContent.trim() === textContent.trim()) {  // ← if content unchanged...
    return;                                          // ← ...bail out early!
  }
  onMessageUpdate(message.id, editContent, editType); // ← fork never reached
};

When you click "Fork Session", the most common case is that you haven't changed the message text — you just want to create a new session from that point. But the early return on the content-unchanged check prevented onMessageUpdate from ever being called. The edit textbox closed (setIsEditing(false)) but no fork happened.

Type of Change

• Feature
• Bug fix
• Refactor / Code quality
• Performance improvement
• Documentation
• Tests
• Security fix
• Build / Release
• Other (specify below)

AI Assistance

• This PR was created or reviewed with AI assistance

Testing

tested locally

[Copilot]

Pull request overview

This PR fixes a bug where the "Fork Session" feature would not work when the message text was unchanged. The issue was caused by an early return in the handleSave function that would exit before calling onMessageUpdate when the content was identical to the original, preventing the fork operation from executing.

Changes:

• Modified the early return condition in UserMessage.tsx to only apply to 'edit' operations, allowing 'fork' operations to proceed regardless of content changes
• Updated the onMessageUpdate type signature in ProgressiveMessageList.tsx to explicitly include the optional editType parameter

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
ui/desktop/src/components/UserMessage.tsx	Fixed early return logic to allow fork operations with unchanged content
ui/desktop/src/components/ProgressiveMessageList.tsx	Updated type signature to properly reflect editType parameter

[zanesq]

Thanks! Tested locally LGTM

[DOsinga]

do we need this change? I don't see the callers being updated to provide a value?

[angiejones]

UserMessage has this which has 3 args:

      if (onMessageUpdate && message.id) {
        onMessageUpdate(message.id, editContent, editType);
      }

but ProgressiveMessageList defied it as only accepting 2 args, so was trying to fix the type