deepseek-ai/DeepSeek-R1
1
0
Fork 0
mirror of https://github.com/deepseek-ai/DeepSeek-R1.git synced 2026-11-05 00:47:42 +00:00
Code Issues 45 Projects Packages Wiki Activity

[GH-ISSUE #844] [Bug] Ghost chat titles reappear after deletion and browser restart (infinite loop) #695

New issue
Closed
opened 2026-10-26 21:25:36 +00:00 by bsakaguchi · 4 comments
bsakaguchi commented 2026-10-26 21:25:36 +00:00
Owner
Copy link

Originally created by @asarmelin on GitHub (May 18, 2026).
Original GitHub issue: https://github.com/deepseek-ai/DeepSeek-R1/issues/844

BUG REPORT – DeepSeek Web

TITLE:
Infinite loop of ghost chat title after deletion: cache vs server desynchronization

SEVERITY SUGGESTION:
Medium-High (affects user trust and system stability perception)

  1. WHAT HAPPENS

  2. User deletes a chat on DeepSeek web.

  3. Chat disappears from the list.

  4. User restarts the browser and opens DeepSeek again.

  5. The deleted chat title comes back (usually named "DeepSeek" or "New Chat").

  6. User clicks on the ghost title:

    • DeepSeek tries to load the chat
    • It fails silently
    • The title is automatically removed from the list

  7. User restarts the browser again.

  8. The same ghost title returns again.

  9. The cycle repeats indefinitely.

Important: The user does NOT manually reload the page (F5) after deleting the chat.

  1. LIKELY TECHNICAL CAUSE

There is a mismatch between two places:

  • Server (backend): chat was deleted (correct)
  • Browser cache (localStorage or IndexedDB): chat still exists (incorrect)

What goes wrong:

When user deletes chat:

  • Server deletes it (OK)
  • Local cache is NOT properly updated (FAIL)

When user restarts browser:

  • DeepSeek reads only from local cache to show the chat list (FAIL)
  • No check with server before showing the list

When user clicks ghost title:

  • System asks server for the chat
  • Server answers "chat does not exist" (404 or similar)
  • Only then the title is removed from the interface (but not from cache permanently)

Next restart:

  • Corrupted cache still has the chat
  • Cycle restarts
  1. WHY THIS HURTS USER EXPERIENCE

The user asked a critical question:

"Doesn't this uncertainty when opening DeepSeek make users feel insecure about the system's stability?"

Real impacts:

  • User cannot trust that a chat was really deleted
  • The system feels haunted or unpredictable
  • User may question:
    • "If the chat list is inconsistent, are the AI answers also unreliable?"
    • "Were my private chats really removed from the server?"

The user explicitly does NOT use manual reload (F5), so the bug is not caused by user behavior.

  1. HOW OTHER PLATFORMS HANDLE THIS

ChatGPT (OpenAI):

  • Minimal local cache
  • Frequent server queries
  • Slower but consistent

Google Drive:

  • Forces full reconciliation on open
  • Users trust what they see

Notion:

  • Cache + aggressive background reconciliation
  • Ghost items are rare

DeepSeek (current):

  • Trusts local cache without server check
  • Fails to invalidate cache after deletion
  • Result: the loop described here
  1. PROPOSED FIX

IMMEDIATE FIX (fix the bug):
When a chat is deleted, the local cache must be invalidated with explicit confirmation from the server.

DEFINITIVE FIX (prevent loops):
Implement reconciliation when DeepSeek opens:

When interface loads:

  1. Show local cache first (for speed)
  2. In background: ask server for the real chat list
  3. Compare IDs from cache with IDs from server
  4. If cache has IDs that server does NOT return:
    • Remove those titles from cache AND from the screen
  5. Update interface to show real state

This keeps speed and guarantees consistency after a few seconds.

  1. WHY THIS MATTERS (user context)

The user is not a software engineer. He is a real user who:

  • Found the bug alone
  • Tested different conditions (restart browser, click ghost title, avoid F5)
  • Made hypotheses about the cause
  • Asked why the system does not reconcile cache and server on open

Most important:

The user questioned the reliability of DeepSeek itself based on this bug:

"If you cannot evolve, learn, identify, and correct your own errors, how trustworthy are your other statements?"

Translation: A UI bug erodes trust in the entire product's intelligence.

This is not just a technical problem. It is a brand trust problem.

  1. EVIDENCE INCLUDED
  • Full conversation between user and DeepSeek (AI assistant)
  • Step-by-step reproduction
  • Conditions for reproduction (browser restart, no F5)
  • Technical cause analysis (cache vs server)
  • Comparison with competitors
  • Proposed fix (short and long term)
  • Impact on user experience and trust

  1. FINAL RECOMMENDATION

  2. Prioritize this bug in the front-end development queue.

  3. Implement cache reconciliation on startup (definitive fix).

  4. Communicate the fix publicly, even briefly, to restore trust.

  5. Consider a more direct channel for technical reports (official GitHub Issues, if available).

END OF REPORT

Originally created by @asarmelin on GitHub (May 18, 2026). Original GitHub issue: https://github.com/deepseek-ai/DeepSeek-R1/issues/844 BUG REPORT – DeepSeek Web TITLE: Infinite loop of ghost chat title after deletion: cache vs server desynchronization SEVERITY SUGGESTION: Medium-High (affects user trust and system stability perception) 1. WHAT HAPPENS 1. User deletes a chat on DeepSeek web. 2. Chat disappears from the list. 3. User restarts the browser and opens DeepSeek again. 4. The deleted chat title comes back (usually named "DeepSeek" or "New Chat"). 5. User clicks on the ghost title: - DeepSeek tries to load the chat - It fails silently - The title is automatically removed from the list 6. User restarts the browser again. 7. The same ghost title returns again. 8. The cycle repeats indefinitely. Important: The user does NOT manually reload the page (F5) after deleting the chat. 2. LIKELY TECHNICAL CAUSE There is a mismatch between two places: - Server (backend): chat was deleted (correct) - Browser cache (localStorage or IndexedDB): chat still exists (incorrect) What goes wrong: When user deletes chat: - Server deletes it (OK) - Local cache is NOT properly updated (FAIL) When user restarts browser: - DeepSeek reads only from local cache to show the chat list (FAIL) - No check with server before showing the list When user clicks ghost title: - System asks server for the chat - Server answers "chat does not exist" (404 or similar) - Only then the title is removed from the interface (but not from cache permanently) Next restart: - Corrupted cache still has the chat - Cycle restarts 3. WHY THIS HURTS USER EXPERIENCE The user asked a critical question: "Doesn't this uncertainty when opening DeepSeek make users feel insecure about the system's stability?" Real impacts: - User cannot trust that a chat was really deleted - The system feels haunted or unpredictable - User may question: - "If the chat list is inconsistent, are the AI answers also unreliable?" - "Were my private chats really removed from the server?" The user explicitly does NOT use manual reload (F5), so the bug is not caused by user behavior. 4. HOW OTHER PLATFORMS HANDLE THIS ChatGPT (OpenAI): - Minimal local cache - Frequent server queries - Slower but consistent Google Drive: - Forces full reconciliation on open - Users trust what they see Notion: - Cache + aggressive background reconciliation - Ghost items are rare DeepSeek (current): - Trusts local cache without server check - Fails to invalidate cache after deletion - Result: the loop described here 5. PROPOSED FIX IMMEDIATE FIX (fix the bug): When a chat is deleted, the local cache must be invalidated with explicit confirmation from the server. DEFINITIVE FIX (prevent loops): Implement reconciliation when DeepSeek opens: When interface loads: 1. Show local cache first (for speed) 2. In background: ask server for the real chat list 3. Compare IDs from cache with IDs from server 4. If cache has IDs that server does NOT return: - Remove those titles from cache AND from the screen 5. Update interface to show real state This keeps speed and guarantees consistency after a few seconds. 6. WHY THIS MATTERS (user context) The user is not a software engineer. He is a real user who: - Found the bug alone - Tested different conditions (restart browser, click ghost title, avoid F5) - Made hypotheses about the cause - Asked why the system does not reconcile cache and server on open Most important: The user questioned the reliability of DeepSeek itself based on this bug: "If you cannot evolve, learn, identify, and correct your own errors, how trustworthy are your other statements?" Translation: A UI bug erodes trust in the entire product's intelligence. This is not just a technical problem. It is a brand trust problem. 7. EVIDENCE INCLUDED - Full conversation between user and DeepSeek (AI assistant) - Step-by-step reproduction - Conditions for reproduction (browser restart, no F5) - Technical cause analysis (cache vs server) - Comparison with competitors - Proposed fix (short and long term) - Impact on user experience and trust 8. FINAL RECOMMENDATION 1. Prioritize this bug in the front-end development queue. 2. Implement cache reconciliation on startup (definitive fix). 3. Communicate the fix publicly, even briefly, to restore trust. 4. Consider a more direct channel for technical reports (official GitHub Issues, if available). END OF REPORT
bsakaguchi 2026-10-26 21:25:36 +00:00
bsakaguchi commented 2026-10-26 21:25:37 +00:00
Author
Owner
Copy link

@maksim-666 commented on GitHub (May 21, 2026):

Please fix the errors in DeepSeek so that it thinks for 2026-2027, etc. Otherwise, it thinks for 2025, which is very strange, of course.

<!-- gh-comment-id:4504122226 --> @maksim-666 commented on GitHub (May 21, 2026): Please fix the errors in DeepSeek so that it thinks for 2026-2027, etc. Otherwise, it thinks for 2025, which is very strange, of course.
bsakaguchi commented 2026-10-26 21:25:37 +00:00
Author
Owner
Copy link

@github-actions[bot] commented on GitHub (Jun 21, 2026):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

<!-- gh-comment-id:4760444113 --> @github-actions[bot] commented on GitHub (Jun 21, 2026): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!
bsakaguchi commented 2026-10-26 21:25:38 +00:00
Author
Owner
Copy link

@github-actions[bot] commented on GitHub (Jul 6, 2026):

false

<!-- gh-comment-id:4888159289 --> @github-actions[bot] commented on GitHub (Jul 6, 2026): false
bsakaguchi commented 2026-10-26 21:25:38 +00:00
Author
Owner
Copy link

@maksim-666 commented on GitHub (Jul 6, 2026):

DeepSeek is broken, the free version of the app and the website are working terribly, the limit has become terrible, in general, I am leaving DeepSeek and recommend it to everyone

<!-- gh-comment-id:4896892934 --> @maksim-666 commented on GitHub (Jul 6, 2026): DeepSeek is broken, the free version of the app and the website are working terribly, the limit has become terrible, in general, I am leaving DeepSeek and recommend it to everyone
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v1.0.0
Labels
Clear labels   
bug

   
closed-as-stale

   
closed-as-stale

   
enhancement

   
pull-request
Mirrored from GitHub Pull Request

  
stale

   
stale
No labels
bug
closed-as-stale
closed-as-stale
enhancement
pull-request
stale
stale
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
deepseek-ai/DeepSeek-R1#695
No description provided.