An application or feature powered by Windows Copilot to assist users with tasks and productivity
Thank you but I'm not willing to waste my precious time on another support agent chat with someone who doesn't care and will just hang up on me again when I restart the browser or reboot the computer. I wasted enough time last time they did that to me and had to shut down projects I was in the middle of.
I've submitted the report via Copilot -> Send Feedback -> Report a Problem.
But I was not willing to share my prompts for privacy and security reasons.
This is clearly an inconsistent message routing and infrastructure load-balancing error causing the service to load an older, cached snapshot of the conversation history rather than the latest committed state.
The University of Pennsylvania listed the incident report as:
CW1530567 - Users may be unable to view recent portions of their conversation history with Microsoft 365 Copilot Chat
| postIncidentReviewPublished | |
|---|---|
| Status: | postIncidentReviewPublished |
| Start Time: | Wed Oct 14 15:55:00 2026 |
| End Time: | Wed Nov 4 21:27:00 2026 |
| Service: | Microsoft 365 Copilot Chat |
| Feature Group: | Microsoft 365 Copilot Chat |
| Classification: | incident |
| Last Updated: | Sat Nov 7 00:20:59 2026 |
| Root Cause: | A latent request routing configuration issue is impacting users' ability to view recent portions of their conversation history with Copilot Chat. |
| Next Update: | N/A |
The penultimate report said:
| Thu Nov 5 01:01:14 2026 | |
|---|---|
| Time: | Thu Nov 5 01:01:14 2026 |
| Description: | Title: Users may be unable to view recent portions of their conversation history with Microsoft 365 Copilot Chat User impact: Users may have been unable to view recent portions of their conversation history with Copilot Chat. More info: The affected conversations weren’t deleted and were temporarily unavailable within conversation history. Some reports indicated that this issue typically occurred when users with an active Copilot Chat left and then reopened the chat. Final status: We’ve completed deployment of the fixes and have received confirmation from a subset of affected customers that the issue is resolved. To ensure you’re using the latest build, please close and reopen the web interface or, if using the app, close and restart it. Scope of impact: Some users were sporadically missing recent portions of their conversation history with Copilot Chat. Start time: Wednesday, October 14, 2026, at 3:55 PM UTC End time: Wednesday, November 4, 2026, at 9:27 PM UTC Preliminary root cause: A latent request routing configuration issue was impacting users' ability to view recent portions of their conversation history with Copilot Chat. Next steps: - We’re continuing to analyze the routing configuration issue to determine why it limited access to conversation history and identify preventative measures to reduce the likelihood of similar impact in the future. We'll provide a preliminary Post-Incident Report within two business days and a final Post-Incident Report within five business days. |
This has NOT been fixed and the issue is NOT resolved.
Does Copilot use parent-pointer tree resolution for the conversation database? Or timestamp-flattened array merging?
This is obviously an "eventual consistency" and load-balancing flaw in the architecture, which was put in place to unify the Personal and M356 infrastructure. When a session token expires and I reload the chat a load balancer routes my request to a read replica. That replica is supposed to be healthy and in sync, but obviously it's routing me to a lagging or misconfigured server node that didn't receive the latest database write before the session closed.
And yes, I know, when the backend database runs an anti-entropy sweep the missing message records will be copied across all storage nodes, but by that time my conversation thread is broken.
If you're using parent-pointer tree resolution, it means any subsequent chat turns since the desync will have created a fork at that turn, and the conversation index's default HEAD pointer will remain locked onto the new branch. I can still find the old branch by searching with the specific #MessageID anchor, but the LLM cannot read that old branch for context in new conversation turns, so they are effectively orphaned.
I am a paying customer and I want this issue resolved on my account shard now.