[Bug] Opening a persisted Copilot conversation can fail with NullPointerException in ChatView.restoreTurn()

Environment

• OS: Windows
• Eclipse Version: 2026-06 (4.40.0)
• Plugin Version: 0.21.0

Describe the bug
Opening an existing GitHub Copilot conversation from the chat history can fail with a NullPointerException while the Copilot Chat view restores the persisted conversation.

The Eclipse Error Log reports:

java.lang.NullPointerException:
Cannot invoke
"com.microsoft.copilot.eclipse.core.persistence.UserTurnData$MessageData.getText()"
because the return value of
"com.microsoft.copilot.eclipse.core.persistence.UserTurnData.getMessage()"
is null

    at com.microsoft.copilot.eclipse.ui.chat.ChatView.restoreTurn(ChatView.java:1931)
    at com.microsoft.copilot.eclipse.ui.chat.ChatView.lambda$8(ChatView.java:315)

After the exception, the affected conversation does not restore correctly and the Copilot Chat view may remain unresponsive.

The problem is reproducible after completely closing and restarting Eclipse, so it does not appear to be caused only by stale in-memory conversation state.

The affected persisted conversation was also inspected externally.

The regular persisted user turns contain message objects with text content. Therefore, the null returned by UserTurnData.getMessage() is not obviously explained by a regular user turn simply containing:

"message": null

or by all user messages being absent from the persisted JSON.

This suggests that either:

• a persisted turn is incorrectly deserialized/classified as UserTurnData,
• a special turn type is not handled correctly during restoration,
• or ChatView.restoreTurn() assumes that UserTurnData.getMessage() can never be null even though the persistence/deserialization layer can produce such a state.

To Reproduce
Steps to reproduce the behavior:

1. Have an existing persisted Copilot Agent conversation in the Eclipse chat history.

2. Completely close Eclipse.

3. Start Eclipse again.

4. Open GitHub Copilot Chat.

5. Select the affected conversation from the chat history.

6. Observe that restoring the conversation fails.

7. Open the Eclipse Error Log.

8. Observe:

   java.lang.NullPointerException:
   Cannot invoke
   "UserTurnData$MessageData.getText()"
   because the return value of
   "UserTurnData.getMessage()" is null
   
   at com.microsoft.copilot.eclipse.ui.chat.ChatView.restoreTurn(...)
   

The issue remains reproducible after a full Eclipse restart.

Expected behavior
Persisted conversations should be restored without throwing an exception.

ChatView.restoreTurn() should not assume that every deserialized UserTurnData necessarily contains a non-null MessageData.

If persisted conversation data contains an unsupported, malformed, legacy, or partially incompatible turn, Copilot should handle it gracefully.

For example, it could:

• skip the invalid turn and continue restoring the conversation;
• log the affected turn ID and reason;
• display a warning that part of the conversation could not be restored;
• or migrate/normalize the persisted turn before rendering it.

A single unexpected persisted turn should not prevent access to the entire conversation.

Screenshots
Not applicable.

The Eclipse Error Log and a sanitized persisted conversation can be provided if required.

Additional context
The affected conversation is a relatively large, long-running Agent conversation containing regular user/Copilot turns as well as Agent/tool-call state.

The persisted JSON was inspected externally.

For the regular user turns:

• a message object is present;
• message.text is present;
• no obvious regular user turn with "message": null was found.

The persisted conversation also contains additional Copilot/subagent turn structures.

This makes it possible that a special persisted turn is being deserialized or interpreted as UserTurnData during restoration even though it does not contain a user message.

The exception occurs specifically during conversation restoration in:

ChatView.restoreTurn(...)

A defensive null check would prevent the complete UI restore from failing, but it would also be useful to determine why a UserTurnData instance without MessageData reaches this code path.

The issue was reproduced after a complete Eclipse shutdown and restart, ruling out a purely in-memory stale-state problem.

A sanitized persisted conversation that reproduces the issue can be provided for investigation.

Start at ChatView.restoreTurn() around ChatView.java:1931 and trace how persisted UserTurnData objects are deserialized and classified, including special Agent or tool-call turns. Reproduce by reopening the affected persisted conversation after restarting Eclipse. Done means the conversation restores without an exception and an invalid or unsupported turn no longer blocks the entire chat view.