Severe Ongoing Copilot Sync Defect: Active Chat Truncation (NOT a "Migration" Issue)

I am documenting a severe, reproducible data persistence and synchronization defect currently affecting the backend of the new Copilot web interface.

Before anyone replies with the standard, copy-pasted script: No, this is NOT the "migration to the new Copilot experience" issue. We were migrated months ago and this has nothing to do with syncing historical conversations. This data loss is happening on brand-new conversations generated long after the migration completed.

The Core Defect: Recent prompts and responses in active, long-running Copilot chats are actively disappearing from the UI. The backend is failing to synchronize the live session state with the stored conversation record.

Here is the exact, reproducible behavior:

1. I am in the middle of a highly technical, long-running workflow. My most recent prompt and Copilot's response vanish upon refreshing or returning to the chat.
2. The missing responses do exist in the backend indexing. If I use the chat search function for a specific string from the missing exchange (e.g., "Phase G"), the search results find it.
3. Clicking that search result restores the conversation window to the correct, fully intact state, including the most recent missing exchanges.
4. If I refresh that exact same page, the recent exchanges instantly vanish again.

I have already verified through exported CSV activity logs, InPrivate/Incognito browsing, and network console monitoring that this is a server-side versioning/indexing failure, not a local cache issue.

Workflow Impact: This bug renders Copilot unusable for serious technical or development workflows. Because the UI and the backend cannot agree on the current state of the chat, I am forced to pause my work. If I simply re-prompt the missing question, I risk injecting duplicate context into the backend and mangling the context window. I have zero confidence in what version of the conversation the LLM is actually "seeing" when it generates a response.

Support Agent Misconduct: When I attempted to escalate this via Live Chat, the Tier 1 support agent utilized the classic "hang up on the reboot" tactic—instructing me to restart Microsoft Edge to clear my cache, and then immediately closing the ticket as "customer disconnected" the moment I complied, dodging the escalation entirely.

I am completely sick and tired of seeing this issue repeatedly dismissed on these forums as a "temporary migration gap." It is a fundamental persistence failure in the current architecture. The fact the bug reproduces in the dedicated Windows Copilot app as well as the Copilot web interface in Microsoft Edge proves this is a backend service failure, not a browser cache issue. The standalone app and the Edge browser do not share the same local session cache, meaning the truncation is actively being served from Microsoft's servers to completely separate client environments.

Can this please be escalated to an actual engineer on the Copilot data persistence team who can look at the server-side telemetry for chat versioning?

System & Environment Details:

• OS: Windows
• Browser/Client: Microsoft Edge (latest version) and the dedicated Windows Copilot App
• Account Type: Personal Microsoft Account with Microsoft 365 Premium
• Isolation Tests Performed: Issue reproduces identically in standard Edge, Edge InPrivate, after completely clearing browser cache/files, and within the standalone Copilot desktop application.