Cross-device conversation sync becomes stale; stale client can hide newer mobile continuation

Summary

Cross-device conversation synchronization can become stale between the ChatGPT iPhone app and Windows/web.

In the failure state, the iPhone continues to receive and send new messages, while the same conversation on Windows/web remains frozen at an older revision. Refreshing the Windows/web client may eventually catch up, but sometimes only after repeated refreshes or a delay.

The more serious failure occurs when the user continues the conversation from the stale Windows/web state: the newer mobile continuation may disappear from the visible conversation, or the two clients can show divergent conversation histories.

This is not just a cosmetic refresh delay. It appears to be a stale-client / conversation-version conflict problem.

Feedback reference

Feedback ID:

no-active-thread-01a0dec2-9d2c-7350-be15-e34062f9bf82

Environment

Account: same ChatGPT account on both devices
Mobile client: ChatGPT iPhone app
Desktop client: Windows/web
Same conversation open on both devices
Reproducible repeatedly
Observed date: September 26, 2026

Observed behavior

1. Mobile advances, desktop stays behind

The iPhone app continues to show newly sent messages and newly received assistant replies.

At the same time, Windows/web can remain on an older conversation state and does not automatically advance to the latest server-side history.

The stale desktop tab still appears usable, even though newer messages already exist on the same conversation from the mobile device.

2. Manual refresh is unreliable

Refreshing/reopening the desktop client sometimes causes the missing messages to appear, but:

it is not immediate,
it may take repeated refreshes,
there is no visible indication that the client is stale,
there is no explicit “refresh conversation from server” action.

This means the user cannot reliably tell whether the desktop is showing the latest authoritative conversation revision.

3. Stale desktop can continue from an old revision

If the user sends a new message from the stale Windows/web state before it catches up, the conversation can diverge.

The newer mobile continuation may then disappear from the visible conversation or become hidden by the continuation created from the stale desktop state.

This creates a data-integrity concern from the user's perspective: a valid conversation continuation appears to have been lost even though it had already existed on another client.

4. No conflict warning

The desktop client currently provides no warning similar to:

“This conversation changed on another device.”
“You are viewing an older revision.”
“Refresh before continuing.”
“Conversation conflict detected.”

The send box remains active, allowing a message to be sent from an outdated local state.

Reproduction steps

Sign in to the same ChatGPT account on iPhone and Windows/web.
Open the exact same conversation on both devices.
Send a message from one device and continue the conversation on iPhone.
Confirm that iPhone shows the newest messages/replies.
Return to Windows/web.
Observe that Windows/web can remain frozen at an older message.
Wait or refresh.
In some cases, the newer messages still do not appear immediately.
Before desktop catches up, send another message from the stale Windows/web state.
Compare the conversation on both devices.
The newer mobile continuation may disappear from the visible history or the two clients may show inconsistent conversation states.

Concrete test performed

During testing, short messages such as:

pc test
repeated pc test messages
SYNC-TEST-3

were used specifically to make it obvious which client had received the latest server-side continuation.

The tests showed that one client could be visibly behind even while the other client had already advanced.

Screenshot evidence already captured

The following screenshots were captured during the failure and show the problem from the user's side.

Screenshot A — Windows/web stale conversation state

Shows the desktop/web conversation still sitting on the two “pc test” messages and corresponding assistant replies while cross-device testing was being performed.

What it demonstrates:

the desktop UI can remain on an older visible revision,
the conversation remains interactable,
there is no warning that the view may be stale.

Screenshot B — repeated sync failure after prior catch-up

Shows that even after the conversation temporarily synchronized, it later stopped updating again.

What it demonstrates:

this is not a single one-off load failure,
synchronization can regress after appearing to recover,
reopening/refreshing is not a dependable permanent fix.

Screenshot C — no available update / no obvious recovery control

Shows the client state while attempting to resolve the problem, with no clear client-side update or manual conversation-sync mechanism available.

What it demonstrates:

the user has no direct recovery action specific to conversation synchronization,
troubleshooting currently depends on refresh/reopen behavior.

Screenshot D — explicit sync test across devices

Shows the conversation after cross-device test messages were sent.

What it demonstrates:

different clients can temporarily expose different conversation revisions,
the issue is visible at the conversation-history level rather than only delayed typing/rendering.

Screenshot E — request for manual sync control

Shows the user explicitly requesting a manual “Sync conversation” action after repeated stale states.

What it demonstrates:

automatic recovery is insufficient for this failure mode,
a manual authoritative-server refresh would provide an immediate recovery path.

Expected behavior

A conversation should have a clearly authoritative server-side revision.

Before a client sends a new message, it should verify that the local conversation revision is current.

If the server has a newer revision, the client should either:

automatically fetch and merge the latest state before sending, or
block the send and inform the user that the conversation changed on another device.

A stale client should never silently create a continuation that causes a newer continuation from another device to disappear from the visible history.

Suggested implementation safeguards

1. Conversation revision / optimistic concurrency check

Each client should track a conversation revision/version identifier.

When sending a new message, include the revision the client believes it is continuing from.

If the server's current revision differs, return a conflict instead of silently accepting a continuation from stale state.

Conceptually:

client_revision != server_revision -> refresh / conflict flow

2. Manual “Sync conversation” action

Add an explicit UI action such as:

Sync conversation
or
Refresh from server

This should:

discard stale local cache for that conversation,
fetch the authoritative server history,
refresh visible messages,
re-establish streaming/subscription state.

3. Visible synchronization status

Show a lightweight state indicator:

Synced
Syncing
Out of date
Conflict detected

This would immediately tell the user whether it is safe to continue from the current client.

4. Preserve both branches on conflict

If two devices genuinely create separate continuations from the same earlier revision, preserve both branches.

Do not silently hide one.

The UI could present:

“Conversation changed on another device”
“Choose latest branch”
or a branch/recovery view.

5. Server-authoritative refresh on focus/resume

When a conversation tab/app returns to foreground after being inactive, compare the local latest message/revision with the server before allowing continued interaction.

6. Realtime subscription health check

If the app relies on a realtime stream/subscription, detect when that subscription becomes stale or disconnected.

A client can otherwise look “online” while no longer receiving conversation updates.

Why this matters

This bug is more serious than ordinary delayed synchronization because the stale client is still allowed to mutate the conversation.

The failure mode is effectively:

Device A advances conversation.
Device B does not receive that update.
Device B still accepts user input.
Device B creates a continuation from obsolete state.
One continuation may disappear from the user's visible history.

That creates a risk of apparent conversation loss and makes cross-device use unreliable for long-running work.

Requested fix

Please consider implementing all three layers:

automatic server-side stale-revision detection,
a visible/manual Sync conversation control,
conflict-safe preservation of divergent continuations.

Even if realtime sync temporarily fails, these safeguards would prevent a stale client from silently continuing from an obsolete conversation state.

Additional Android/macOS reproduction: locally visible mobile turns were absent from current thread state and disappeared after reload

I reproduced a closely related cross-device state divergence on 2026-10-04 using the ChatGPT Android app and ChatGPT macOS desktop app on the same account and same conversation.

To make missing turns unambiguous, I prefixed messages with sequence numbers and originating device.

The relevant sequence was:

006
007 Android
008 Android
009 Android
010 MacBook

Before reloading the Android conversation, messages 007, 008, and 009 were visibly present in the Android UI, and I captured screenshots of all three.

However:

the same messages were absent from the macOS conversation;
the current ChatGPT conversation context did not contain 007–009;
after closing and reopening the same conversation on Android, 007–009 disappeared from Android as well.

Observed sequence:

Android message sent
→ visibly present in Android UI
→ absent from macOS / current conversation state
→ Android conversation closed and reopened
→ previously visible Android message disappears

This reproduction occurred in a newly created conversation, within approximately one hour of creation, so a long-running conversation does not appear to be a necessary condition.

Other conversations were syncing normally around the same period, and MacBook → Android synchronization also succeeded in cases where Android-originated turns were missing.

I am not claiming that this has the same root cause as the original report. The additional evidence is that a mobile client can display messages as successfully present even though those messages are apparently not part of the conversation state visible to another client or to the current assistant context, and a reload can then remove the locally visible turns.

I have screenshots showing 007, 008, and 009 before reload and can attach them if useful.

Screenshot evidence before Android reload

These screenshots were captured before closing and reopening the affected Android conversation. They show messages 007, 008, and 009 visibly present in the Android UI before those same turns disappeared after reload.

Follow-up: controlled stale-client continuation reproduced the previously suspected failure pattern

I performed a more controlled cross-device test on 2026-10-05 JST after noticing the same conversation-state divergence again.

Before the test:

Android contained a newer continuation that was not visible on macOS.
macOS remained at an older conversation state.
Closing and reopening the conversation on Android did not remove the Android-only continuation; it remained visibly present.

I preserved screenshots and an external handoff before continuing.

Based on earlier incidents, I suspected that sending a new message from the stale macOS state might cause the newer Android-only continuation to disappear or otherwise be reconciled away.

I then sent a short, uniquely identifiable message from macOS:

MAC-SYNC-TEST-001

The resulting behavior was consistent with the previously suspected pattern: continuing from the stale macOS state caused the Android-visible continuation to no longer remain available in the same way.

A more complete observed sequence is:

Android advances conversation
→ macOS remains on older state
→ Android continuation survives Android close/reopen
→ macOS sends from stale state
→ newer Android continuation is no longer preserved as before

This makes the earlier disappearance incidents look less like an Android reload problem by itself and more like a possible stale-client continuation / reconciliation conflict.

This still does not establish the implementation-level cause.

In particular, I cannot determine whether the behavior involves:

a stale conversation revision,
branch selection,
server-side reconciliation,
client-side state replacement,
or another conversation-state mechanism.

The stronger user-facing observation is:

A message sequence that is visibly present on one device can be lost or hidden after another device continues from an older conversation state.

This also means my earlier reproduction, where Android messages disappeared after reload, may have exposed the result of an earlier stale-client conflict rather than the reload itself being the trigger.

That interpretation remains a hypothesis, but this controlled reproduction is consistent with it.

Higher-level observation: this may be a conversation-consistency problem rather than isolated UI symptoms

After observing several related manifestations, I want to add one higher-level user-facing invariant without claiming an implementation-level root cause.

The individual symptoms have varied:

one device advances while another remains stale;
messages are visible on one client but absent from another;
a reload can change which messages are visible;
continuing from a stale client can make a newer continuation disappear or become hidden;
in another reproduction, bidirectional live synchronization temporarily stopped and recovered after reopening the thread.

These do not necessarily share one root cause.

However, they appear to violate the same user-facing consistency expectation:

A message shown as successfully sent
should not silently become unavailable
because another client has an older conversation state.

More generally:

client-visible state
≠ necessarily canonical conversation state

may currently be an observable failure boundary.

From the outside, this looks less like one isolated rendering bug and more like a broader cross-device conversation consistency / reconciliation problem.

Possible implementation areas might include revision tracking, stale-client detection, reconciliation, subscription recovery, or persistence acknowledgement, but I am not asserting any of these as the cause.

The important safety property is:

A stale client should not be able to continue in a way that silently hides, replaces, or loses turns already shown as successfully sent on another device.

+1 to the proposed manual Sync conversation / Refresh from server control, especially for the Windows app.

I have repeatedly had the inverse direction as well: a conversation progresses on the web, but the Windows app can remain on an older visible state. When that happens, there is currently no obvious way to tell whether the Windows transcript is authoritative or stale.

A practical Windows UX could be:

a small Refresh conversation button/menu action in the conversation header;
on use, re-fetch the authoritative server-side history for that thread;
invalidate stale local transcript/cache state;
re-establish the conversation-update subscription;
preserve any active turn safely;
then show a simple status such as Synced, Updated, or Already up to date.

It would also be useful if the app automatically detected that the server has a newer conversation revision and showed something like:

This conversation changed on another client. Refresh before continuing.

That would help prevent continuing from an older Windows state and reduce the risk of apparently missing or divergent conversation branches.

This would be useful even after the underlying sync bug is fixed, because a manual refresh gives users a recovery path when realtime synchronization temporarily fails.

OBS-007 — macOS native app showed stale history; full app restart restored it (2026-10-10 JST)

Adding a further observation, with the observed behavior separated from an untested hypothesis.

Observed facts

On 2026-10-10 JST, I compared the same conversation across three environments:

ChatGPT on Android: showed the latest conversation history.
ChatGPT Web in Safari on the Mac: showed the latest conversation history.
ChatGPT macOS native app: showed an older history that only extended through the previous day.

In the same macOS app, another conversation successfully synchronized the latest messages sent from Android. The stale state was therefore not observed in every conversation in the app.

Recovery sequence

I switched away from the affected conversation and then returned to it in the macOS app. This did not restore the missing history.
I fully quit the app with Cmd+Q and relaunched it.
After relaunching, the full conversation history was visible again.
I then successfully sent a new message from the Mac.

H-01 — untested hypothesis for this incident

Sending a message from the Mac while its conversation view is stale might lead to inconsistent history or apparent disappearance of newer turns.

I did not send any message from the stale macOS state during OBS-007. The successful Mac message was sent only after the restart had restored the full history. This incident therefore does not establish a causal link between writing from a stale client and history inconsistency/disappearance.

Planned follow-up

I plan to use a disposable test conversation with uniquely identified messages and compare the results across Android, Safari on the Mac, and the macOS native app.

This observation does not establish server-side data loss or an implementation-level root cause, nor does it establish that this incident and the earlier reports share the same cause.

OBS-007 follow-up — sign-out/sign-in restored sync twice

When the ChatGPT macOS app on my MacBook was missing the latest conversation history, I did not send a new message from the stale client. Instead, I signed out and signed back in; the latest history then synchronized correctly. This recovery sequence has succeeded twice. This adds a second observed recovery method alongside the previously reported Cmd+Q → relaunch.

For context, in earlier incidents, after I sent from an unsynchronized client, newer conversation turns also disappeared from view on the original device where they had been visible. Actual server-side deletion and a causal relationship remain unconfirmed.

As a provisional precaution, I recommend avoiding new messages from a stale client until the latest history is visibly restored. These two successful recoveries do not establish that sign-out/sign-in reliably prevents history loss or resolves the underlying cause.

Independent RETIS observations relevant to OBS-007

We've been conducting a series of Windows desktop / Firefox synchronization and conversation-retrieval experiments since August 2026, which we call RETIS.

Our earlier observations showed that Recents visibility, explicit conversation Search, and information independently retrievable by the assistant did not always agree. We previously documented these observations in #43276.

A further controlled continuity test on 10 October produced two contrasting results:

RETIS-6A: The desktop assistant independently retrieved the original conversation and its exact sentence/codeword from the original assistant message.

RETIS-7A: The assistant retrieved records from the identified original conversation, but the returned message content did not expose the original sentence/codeword. Some entries contained content-reference markers rather than the underlying text.

We also tested whether supplying an exact ChatGPT conversation URL would allow independent retrieval through personal-context search. That attempt returned no matching conversation, although this does not establish that content-based retrieval would fail.

These findings reinforce the importance of distinguishing conversation persistence, client-visible history, conversation discovery, and the contents actually returned by retrieval tools.

Your OBS-007 result—where restarting the desktop client restored messages already visible on other clients—is particularly interesting alongside our earlier restart and continuity observations.

We have not demonstrated permanent message loss, nor do we claim that our observations and yours necessarily share a root cause. We have retained detailed experimental notes if they would be useful.

Additional observation — macOS desktop sync divergence and sign-in recovery (2026-10-13 JST)

I have continued observing intermittent conversation synchronization divergence between ChatGPT Android and the macOS desktop app.

Observed pattern so far (counts not yet systematically recorded):

In all sync-divergence incidents I have personally observed so far, the stale view was on the Mac desktop side. In particular, messages sent from Android sometimes failed to appear in the same conversation on Mac, even when that conversation was already open.
In all cases where I tried signing out and signing back in on the Mac app, the missing messages reappeared and synchronization resumed. These are 100% of observed cases / attempted recoveries to date, not a claim of a 100% reproduction rate.
Other conversations could still be opened and used on Mac while an affected conversation remained stale.
The same Android-to-Mac workflow also synchronizes normally at other times, including a check immediately before this update.
The issue can occur repeatedly in a single day; I plan to begin recording daily incident counts to quantify frequency.

Related but distinct recent observation: An assistant answer was initially visible in an open Mac conversation. After the Mac had been asleep with the conversation left open, the answer and its reasoning display were no longer visible on Mac. The answer remained visible on Android, and the conversation continued from Android with earlier context still available. This does not establish server-side deletion or that sleep caused the disappearance.

Precaution: When I detect a stale Mac conversation, I avoid sending from that stale view because of previous observations of cross-device visible-history regression following a stale-client send. I sign out and back in on Mac and verify the latest history before resuming.

Assessment: Root cause remains unknown. Potential areas for investigation include per-conversation update state, reconnection/update subscriptions, session lifecycle, and cache invalidation. Recovery after signing back in does not by itself prove an authentication timeout or identify the failing component.

Related reports for comparison (OBS-007 follow-up)

I found two potentially relevant existing reports and am linking them as comparative evidence, not confirmed duplicates or evidence of a shared root cause.

Assistant replies missing from desktop history after using voice mode on mobile #43267 — Assistant replies missing from desktop history after using voice mode on mobile: The reporter describes assistant replies visible on mobile but missing from the macOS desktop conversation, while user messages and “Worked for…” indicators remain visible. This is particularly similar to my recent assistant-response-body visibility observation: the Android app displayed the final response, while Mac showed reasoning/tool-activity indicators without the final answer. Important differences: Assistant replies missing from desktop history after using voice mode on mobile #43267 involved mobile voice mode, and some missing replies reportedly remained absent after restarting desktop; in my latest observation, signing out and back in on Mac restored the missing answer.
ChatGPT mobile SSH sessions do not live-sync back to Codex App and can conflict with active macOS app sessions #29094 — ChatGPT mobile SSH sessions do not live-sync back to Codex App: This report describes new turns failing to live-sync into the macOS app until restart and warns about stale concurrent state. It is relevant to the stale desktop state symptom, but uses a mobile-to-Codex SSH/CLI workflow, not the ordinary Android app ↔ macOS app workflow I observed.

For clarity, I am tracking two symptom categories separately:

OBS-007-A: cross-device visible-history sync divergence — Mac remains on older conversation history while Android has newer turns.
OBS-007-B: assistant response body not visible on Mac — Mac shows the user turn and reasoning/tool activity but not the final assistant answer, which is visible on Android.

Both symptom types have recovered after signing out and back into the Mac app in my observed recovery attempts, but this does not establish a common cause. I am starting to count incidents per day and will distinguish affected conversations from separate incidents.

Related: #43267 and #29094

Additional related report — #53540 (comparative observation, 2026-10-13)

A newly reported case, #53540 — “[ChatGPT Web] Completed assistant answers disappear after next message; Thinking summary remains”, provides a useful cross-platform comparison for OBS-007-B (assistant response body visibility failure).

Overlap: The user-visible assistant final answer is absent while Thinking/reasoning-duration or activity indicators remain present. Both reports leave open whether the response is missing from storage, retrieval, or client-side presentation.

Important differences:

[ChatGPT Web] Completed assistant answers disappear after next message; Thinking summary remains #53540: ChatGPT Web, Windows/Edge, ordinary conversation; an answer previously visible disappears after a subsequent user message. Server persistence and recovery behavior have not been established.
My OBS-007-B observation: ChatGPT macOS desktop app lacks a completed final answer that remains visible on Android for the same conversation. Signing out and back into the Mac app restored the answer in my observed attempt(s).

This broadens the set of comparable symptoms beyond macOS, but does not demonstrate a shared defect, shared backend, or common root cause. It also does not establish that any missing response was deleted server-side.

Related issue: #53540

For tracking, please keep this as external comparative evidence, separate from my own directly reproduced Android/macOS observations.

OBS-007-B follow-up — macOS desktop vs Web comparison (2026-10-14 JST)

Additional directly observed evidence from the same user's environment:

Frequency: On October 14 (JST), the macOS desktop app exhibited the assistant-final-answer-body visibility failure three times by approximately 11:40 JST. This symptom is currently occurring more frequently in my use than the separate cross-device stale-history symptom (OBS-007-A). Counts are user-observed, not a controlled reproduction rate.
Specific symptom: The assistant's final answer body is absent in the Mac desktop app while the Thinking/reasoning/activity indicators remain visible.
New cross-surface comparison: I checked ChatGPT Web on the same MacBook for the affected conversation. The answer body was visible on Web but missing in the native macOS desktop app. This is a useful isolation result: the failure is not uniform across clients on the same computer.
Recovery procedure: In all recovery attempts so far where I have signed out and back into the Mac desktop app, the missing content has reappeared. Put differently, the sign-out/sign-in recovery procedure has been reproducibly successful in the observed attempts (100% of attempted recoveries to date). The exact denominator has not been systematically recorded, and this is not a claim that the original defect reproduces 100% of the time or that all three incidents today have individually been retested with sign-in.
Safety practice: I avoid sending new turns from a client displaying stale or incomplete conversation state until the current conversation is verified.

Interpretation: These observations prioritize investigating the macOS desktop client's conversation-state retrieval, cache/session lifecycle, or presentation/hydration behavior. They do not identify a root cause or prove that missing messages were deleted from server storage. The Web-vs-desktop comparison is stronger evidence against a machine-wide display problem than earlier Android-vs-Mac comparisons.

Related comparative report: #53592 describes missing desktop final answers while the underlying final_answer was reportedly present in thread records, but its environment differs and a shared root cause is not established.

OBS-007-A — hypothesis for investigation: stale-client write may select an incomplete conversation continuation (2026-10-14 JST)

I would like to add a more specific unverified failure hypothesis to my earlier Android/macOS observations. This is an investigation lead, not a claim about ChatGPT's internal architecture or a confirmed root cause.

Two observed paths from a stale macOS conversation

Path A — write before recovery (history becomes unavailable):

I send new turns from ChatGPT Android.
The macOS app does not display those newer turns and remains on an older conversation state.
I send another turn from that still-stale macOS view.
The previously visible Android continuation subsequently disappears from the visible conversation history, including on Android.
I have not been able to recover those missing turns through the recovery attempts available to me.

This pattern was tested and described in more detail in my October 5 follow-up.

Path B — refresh state instead of writing (latest turns become visible):

I send new turns from Android.
The macOS app remains stale.
I do not send a new turn from macOS. Instead, I sign out and sign back in on the Mac.
The missing latest Android turns then appear on macOS.

This recovery has been observed in multiple attempts, as reported previously. It does not mean that turns already lost in Path A are restored by signing in again.

Hypothesis — stale state treated as the active continuation

Could a new write from a client holding an older conversation revision cause that client's incomplete continuation, or a branch based on it, to be treated as the active/canonical conversation path and propagated to other clients?

Illustrative conceptual sequence (not a description of the actual implementation):

Android visible:  001 → 002 → 003 → 004 → 005
macOS stale:      001 → 002 → 003

macOS sends 006 from stale view

Possible active path shown afterward:
                  001 → 002 → 003 → 006
                                  004/005 no longer visible

A last-writer-wins-like state selection, branch-head switch, or erroneous reconciliation could potentially produce this appearance. None of these mechanisms has been verified, and the observation does not establish that any messages were physically deleted from server storage. An independent persistence or retrieval failure could also explain some symptoms.

Specific investigation request

Could the team check whether, when a macOS client submits a turn against a stale conversation state:

the write carries an expected/base conversation revision or parent message ID;
the server detects and safely handles a mismatch with the latest persisted continuation;
writing from an older revision can change the conversation's active branch/head or client-visible history;
other devices subsequently receive a truncated/alternate view even if older turns remain stored;
an apparently successful send is durably persisted and remains discoverable after reconciliation?

The core distinction is “latest write” is not necessarily “latest complete conversation history.” Even if clients are briefly stale, continuing from one should not silently make already visible/sent messages inaccessible.

Please keep this as OBS-007-A (cross-device history divergence), separate from my OBS-007-B (macOS assistant-answer-body rendering/visibility) observations. The two symptoms need not share a root cause.

Status: HYPOTHESIS / UNVERIFIED.

OBS-007-A — concise clarification of the stale-write hypothesis (2026-10-14 JST)

Detecting a new write does not make the writing client's entire local conversation state the latest authoritative state.

In Japanese: 「最新の書き込みを検知しても、その書き込み元の状態全体を最新として採用してはいけない。」

For example, Android may already display turns 001 → 002 → 003 → 004 → 005, while an unsynchronized macOS client displays only 001 → 002 → 003. If macOS then sends turn 006, the newness of turn 006 does not establish that the macOS client's incomplete view is the complete or authoritative conversation history.

The distinction is between a new write event and the completeness/currency of the writer's base state. A potential investigation question is whether stale-client writes are checked against the current conversation revision or reconciled without treating the stale base as canonical.

Unverified hypothesis only: This is a general design principle and a possible explanation for the observed visible-history regression, not evidence that ChatGPT internally uses last-writer-wins, replaces canonical state, or deletes server-side messages. No additional risky stale-write test was performed for this clarification.

Related earlier hypothesis: #48490 (comment)

Cross-device conversation sync becomes stale; stale client can hide newer mobile continuation #48490

Description

Summary

Feedback reference

Environment

Observed behavior

1. Mobile advances, desktop stays behind

2. Manual refresh is unreliable

3. Stale desktop can continue from an old revision

4. No conflict warning

Reproduction steps

Concrete test performed

Screenshot evidence already captured

Screenshot A — Windows/web stale conversation state

Screenshot B — repeated sync failure after prior catch-up

Screenshot C — no available update / no obvious recovery control

Screenshot D — explicit sync test across devices

Screenshot E — request for manual sync control

Expected behavior

Suggested implementation safeguards

1. Conversation revision / optimistic concurrency check

2. Manual “Sync conversation” action

3. Visible synchronization status

4. Preserve both branches on conflict

5. Server-authoritative refresh on focus/resume

6. Realtime subscription health check

Why this matters

Requested fix

Activity

kouteichan commented on Oct 4, 2026

Additional Android/macOS reproduction: locally visible mobile turns were absent from current thread state and disappeared after reload

kouteichan commented on Oct 4, 2026

Screenshot evidence before Android reload

kouteichan commented on Oct 4, 2026

Follow-up: controlled stale-client continuation reproduced the previously suspected failure pattern

kouteichan commented on Oct 8, 2026

Higher-level observation: this may be a conversation-consistency problem rather than isolated UI symptoms

MAVIS-creator commented on Oct 9, 2026

kouteichan commented on Oct 10, 2026

OBS-007 — macOS native app showed stale history; full app restart restored it (2026-10-10 JST)

Observed facts

Recovery sequence

H-01 — untested hypothesis for this incident

Planned follow-up

kouteichan commented on Oct 10, 2026

OBS-007 follow-up — sign-out/sign-in restored sync twice

Whitelaughter commented on Oct 11, 2026

kouteichan commented on Oct 12, 2026

Additional observation — macOS desktop sync divergence and sign-in recovery (2026-10-13 JST)

kouteichan commented on Oct 13, 2026

Related reports for comparison (OBS-007 follow-up)

kouteichan commented on Oct 13, 2026

Additional related report — #53540 (comparative observation, 2026-10-13)

kouteichan commented on Oct 14, 2026

OBS-007-B follow-up — macOS desktop vs Web comparison (2026-10-14 JST)

kouteichan commented on Oct 14, 2026

OBS-007-A — hypothesis for investigation: stale-client write may select an incomplete conversation continuation (2026-10-14 JST)

Two observed paths from a stale macOS conversation

Hypothesis — stale state treated as the active continuation

Specific investigation request

kouteichan commented on Oct 14, 2026

OBS-007-A — concise clarification of the stale-write hypothesis (2026-10-14 JST)

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions