feat: implement incremental message updates for improved UI performance

[hannesrudolph]

Fixes #6513

Summary

This PR implements incremental message updates to significantly improve UI performance, especially for tasks with many messages.

Problem

Previously, the entire application state (including all messages) was sent to the webview on every message creation or update. This caused performance issues with large message histories, as the UI had to re-render all messages each time.

Solution

• Modified the message handling to send only new or updated messages instead of the entire state
• Added new message event types: messageCreated and messageUpdated
• Enhanced the webview handler to process incremental updates
• Extended the feature to handle existing tasks loaded from history

Changes

1. Task.ts: Modified addToClineMessages and updateClineMessage to send only the affected message
2. ExtensionMessage.ts: Added new message types for incremental updates
3. ExtensionStateContext.tsx: Updated webview handler to process incremental messages
4. ClineProvider.ts: Enhanced postStateToWebview to handle existing tasks with incremental loading

Benefits

• Reduced data transfer between extension and webview
• Minimized UI re-renders
• Improved responsiveness, especially for long-running tasks
• Consistent experience for both new messages and historical messages

Testing

• Verified that new messages are sent incrementally
• Confirmed that message updates work correctly
• Tested loading existing tasks from history with incremental message loading
• All linting and type checks pass

This change provides a significant performance improvement for the UI without changing the user experience.

---

Important

Implement incremental message updates in Task.ts for improved UI performance by reducing data transfer and minimizing re-renders.

• Behavior:
  • Incremental message updates implemented in Task.ts to send only new or updated messages to the webview.
  • New message event types messageCreated and messageUpdated added in ExtensionMessage.ts.
  • ExtensionStateContext.tsx updated to handle incremental message updates.
• Performance:
  • Reduces data transfer and minimizes UI re-renders, improving responsiveness for tasks with many messages.
• Testing:
  • Verified incremental sending of new messages and correct handling of message updates.
  • Tested loading existing tasks from history with incremental message loading.

^{This description was created by for b5b5b8e. You can customize this summary. It will automatically update as commits are pushed.}

[Copilot]

Pull Request Overview

This PR implements incremental message updates to improve UI performance by sending only new or updated messages to the webview instead of the entire application state. The solution reduces data transfer and minimizes UI re-renders, especially beneficial for tasks with large message histories.

Key changes include:

• Modified message handling to send individual messages instead of full state updates
• Added new message event types (messageCreated and messageUpdated) for granular updates
• Enhanced webview state management to process incremental updates
• Implemented special handling for loading existing tasks with gradual message rendering

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
ExtensionStateContext.tsx	Added handler for messageCreated events to append new messages to state
ExtensionMessage.ts	Added messageCreated message type to support incremental updates
ClineProvider.ts	Enhanced postStateToWebview to send messages incrementally for existing tasks
Task.ts	Modified message methods to send individual message updates instead of full state

[Copilot]

The provider is retrieved multiple times in this method (lines 1655, 1666). Consider extracting it once at the beginning of the method to avoid duplication.

[roomote]

Thank you for your contribution! I've reviewed the changes and found some issues that need attention. The implementation successfully reduces data transfer and improves UI performance, but there are a few areas that could be improved for robustness and maintainability.

Review Findings:

Critical Issues:

1. Magic number in delay (ClineProvider.ts:1349) - The hardcoded 10ms delay should be extracted to a named constant with documentation
2. Duplicate provider retrieval (Task.ts:1655,1666) - The provider is retrieved twice in the same method

Important Suggestions:
3. Performance concern - The 10ms delay per message could cause noticeable delays for tasks with many messages (100 messages = 1 second)
4. Missing error handling - The postStateToWebview method doesn't handle potential errors when sending messages incrementally
5. Type safety issue - The clineMessage property in ExtensionMessage is optional but used without null checks

Minor Improvements:
6. Code duplication - Similar logic for sending individual messages is repeated in multiple places in Task.ts
7. Missing tests - No unit tests mentioned for the new incremental loading functionality

Note: One of Copilot's comments about a missing delay import is incorrect - the import exists on line 7 of ClineProvider.ts.

[hannesrudolph]

Thank you for your contribution! I've reviewed the changes and found that the implementation successfully improves UI performance through incremental message updates. The critical issues from the previous review have been addressed.

Summary

This PR effectively reduces data transfer and minimizes UI re-renders by sending only new or updated messages instead of the entire state. The implementation is solid with proper error handling.

Resolved Issues from Previous Review

✅ Magic number in delay - now uses constant
✅ Type safety issue - code now uses non-null assertions appropriately
✅ Missing error handling - now has try-catch with logging

I've left some suggestions inline for further improvements, primarily around performance optimization for very large message histories and code organization.

[hannesrudolph]

This pattern of updating and sending messages is repeated in multiple places. Could we extract it into a helper method to reduce duplication?

[daniel-lxs]

LGTM

[daniel-lxs]

@roomote-agent Use switch_mode to switch to pr-fixer mode and solve the issues on this PR. Do not create a new one.

[roomote]

Hi @daniel-lxs! I see your request and I'm now working on fixing the issues with this PR.

I've identified that the PR has merge conflicts that need to be resolved. I'll resolve these conflicts and ensure all tests pass before pushing the changes.

I'll update you once the fixes are complete.

[roomote]

✅ @daniel-lxs PR #6522 has been successfully fixed!

Summary of fixes applied:

Merge Conflicts Resolved

The PR had merge conflicts in src/core/task/Task.ts that have been successfully resolved by:

• Combining the incremental message update feature with error handling improvements
• Adding try-catch blocks around postMessageToWebview calls for robust error handling
• Using RooCodeEventName.Message constant instead of string literals for event names
• Preserving both the performance optimization (incremental updates) and stability improvements (error handling)

CI Status

All CI checks are now passing:

• ✅ Unit tests (Ubuntu & Windows)
• ✅ Integration tests
• ✅ Code analysis & linting
• ✅ Compilation
• ✅ Translation checks

The PR is now ready for merge with all conflicts resolved and tests passing.