[Bug] Ghost chat titles reappear after deletion and browser restart (infinite loop)

[asarmelin]

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.

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

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

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

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

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

END OF REPORT

[maksim-666]

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.