Silent truncation of trailing content in very large documents (~180k–220k+ words), discovered long after the fact

[Blackhawke]

Summary

We've repeatedly lost large blocks of content — thousands of words at the end (bottom) of a document — with no crash, no error, and no indication at the time it happened. We only discover it later, sometimes much later, when we scroll down or check the word count and find the tail of the document gone. This is distinct from #6618 (a report we filed a couple of days ago about the buffer clearing instantly and visibly while typing) — this is silent and delayed, and only seems to happen on very large files.

Environment

Same two machines/setups as #6618:

• Linux: Typora 1.14.9, Debian GNU/Linux 12 (bookworm), x64
• Windows: current release (updated within the last few days), Windows 11 Home, version 25H2, OS Build 26200.8875

History / file sizes involved

This isn't new — it's actually older and has happened more than once:

• While assembling and doing final edits on a previous full-length manuscript (~185,000 words at final length), the file was in the ~220,000-word range during the final edit pass (before final trims), and we lost the last chapters this way several times during that process.
• It just happened again this morning on a new manuscript, currently ~187,000 words — we lost roughly 10,000 words from the bottom of the file.
• In both cases, the file in question is a single large document assembled by combining individual chapter files together for editing — not something typed from scratch at that size in one sitting.

Observed pattern

• The loss is always at the end/bottom of the document, not wherever we're actively editing.
• We were editing higher up in the document (an earlier chapter/section) when it happened, both times we've been able to narrow it down — it does not seem to happen while actively working in the section that ends up truncated.
• Because there's no crash, error, or visible change at the moment it happens, we have no way to pinpoint exactly when the truncation occurs — we only notice it later during a scroll-through or word-count check.
• Autosave is enabled on both machines. We have never seen the autosave draft files described in the Version Control / Recovery documentation ({date}-{filename}.md via Preferences → File → "Recover Unsaved Drafts") appear on either machine, despite autosave being on.

Mitigation / why we haven't lost everything permanently

We keep the individual chapter files as source of truth separately from the combined working file, and the whole project is under git version control. That's what has saved us both times — a git revert HEAD~1 for the earlier manuscript, and simply re-assembling from the original chapter files this time. Without that safety net, this would have been permanent, uncorrectable data loss both times.

Possibly related

• Editor buffer suddenly clears entirely while typing — no crash, no error, unsaved changes lost #6618 (filed by us a couple of days ago) — a related but distinct symptom: the whole buffer clearing instantly and visibly during normal editing, with no crash. We suspect these may share a root cause in how large buffers are handled, but they're different enough in presentation (instant + visible vs. delayed + silent) that we filed them separately.
• Severe performance degradation and sidebar lag with large documents (>10,000 words) #6542 ("Severe performance degradation and sidebar lag with large documents (>10,000 words)") — not the same bug, but it establishes that Typora already has known issues scaling past 10,000 words. Our files are 15–20x that size, well outside any range that appears to be well-tested, which may be relevant context for why buffer/save handling breaks down here specifically.

Why this report is light on precise repro steps

We don't know the exact trigger or moment it happens, only the pattern above — and there's a specific reason for that: the section that ends up getting truncated is far enough below where we're actually working that we have no visibility into it at the time. It's not just off-screen from our current cursor position — it's below what the Outline panel in the sidebar even shows us. We have no way to notice something's wrong in real time when the affected content isn't visible anywhere in the UI, including the navigation aid meant to give us a view of the whole document. We're filing this now, with the details we can reconstruct, rather than waiting for a clean reproduction we may never get — given it's cost us real manuscript content more than once. Happy to provide anything else that would help (exact chapter/file structure, Typora settings, etc.) if it's useful.