Skip to main content
All postsEngineering

Where did my chat history go? A post-mortem

For a while, a Build thread with Lindi Code could vanish between a reload and a return. It had four causes, all real. This is what they were, and the rule we now hold everything to: the database is the source of truth.

1 min readThe Lindi team

A conversation with Lindi Code is work. It holds the plan, the screens built so far, the things you asked for and the things you rejected. Losing it is not an inconvenience; it is losing an afternoon. For a while, that could happen. We owe the people it happened to an account of why.

Four causes

  • The thread lived in the browser’s local storage. That survives a reload on the browser that wrote it and nothing else — not cleared site data, not a second device. Worse, the write failed softly past the storage quota, so a large session silently stopped saving while the editor looked fine.
  • On some loads the thread was keyed to a placeholder identity, because the editor attached before it knew who you were. The same person, same file, same browser could reload into an empty thread stored under a different key.
  • A hydration race could restore an older snapshot over a newer one.
  • Two brands sharing one storage namespace could shadow each other’s threads.

The rule now

The database is the source of truth for chat history. Local storage and client state are caches in front of it: they may make a reload paint faster, they may never be the only copy of anything. The thread attaches only once the session is known, so it is never keyed to a placeholder. And the caches are namespaced by brand, user and document, so nothing shadows anything.

The thread, the comments and the version history beside the screen — all of it now stored where a reload cannot lose it.

A cache that can be the only copy of something is not a cache. It is a bug waiting for a quota.

If you lost a thread during that period, we are sorry. If it happens again, it is a new bug, and we would like to hear about it.