Sorry It’s a lengthy reply. I posted the logs to Grok, here’s what it had to say:
The logs show a classic sequence of events with Obsidian LiveSync (the self-hosted sync plugin by vrtmrz) that unfortunately can lead to files appearing to vanish, especially during or right after an internet disconnection. You’re right to suspect a bug or edge-case behavior in the plugin — it’s not uncommon, and your logs point to a known class of issues.
What Likely Happened to “outfox.energy.md”
Normal sync behavior earlier (14:45): The plugin initializes, collects files (~1,675 in your DB), skips large PDFs (good), and successfully syncs/updates storage and database. At this point, everything looks healthy.
Internet disconnection at 17:12: Multiple repeated errors:
Failed to fetch: Error:net::ERR_INTERNET_DISCONNECTED
This happens when the plugin tries to reach your CouchDB server (self-hosted remote DB) but can’t because your internet dropped. LiveSync is very aggressive about checking connectivity and replicating in real-time, so it spams these logs when offline.
After reconnection (17:26 onward): Replication reactivates repeatedly, and the plugin starts pulling/pushing again. You see many STORAGE → DB (plain) Usernames & Passwords/outfox.energy.md entries — this means the plugin is repeatedly writing (or re-writing) the file from storage to the local DB index.Then suddenly, at some point (not explicitly logged in the snippet, but implied by your description), the file disappears from your local vault. The earlier log at 14:45:03 shows a similar pattern with a deletion:
xxx ← STORAGE (deleted) Usernames & Passwords/outfox.energy.md
This indicates LiveSync sometimes interprets a sync state mismatch (especially after a disconnect/reconnect) as the file being “deleted” on the remote side or needing removal locally to resolve a conflict.
LiveSync’s replication logic can be fragile during brief outages:
It uses chunk-based storage (files split into small pieces).
If a disconnect interrupts a replication cycle, it may end up in an inconsistent state where the plugin thinks the remote DB has no entry for the file (or a deleted/missing chunk marker), triggering a local deletion to “sync” to that perceived state.
This is exacerbated if there are any pending local changes to the file (e.g., you were editing the Outfox tariff note during/near the disconnect).
This isn’t “losing files over internet connection” in the sense of corruption — it’s a sync conflict resolution gone wrong, where the plugin errs on the side of deleting locally to match what it thinks is the authoritative remote state.
Is This a Known Bug in LiveSync?
Yes — similar issues have been reported in the plugin’s GitHub repo and Obsidian forums over the years (including 2025–2026):
Files disappearing or getting deleted unexpectedly after sync interruptions, disconnects, or replication loops.
Problems with deletion propagation (sometimes deletions don’t sync, other times they propagate too aggressively).
Edge cases after network errors leading to local files being removed to “resolve” perceived mismatches.
Replication getting stuck in “activated” loops after reconnect, which can cause inconsistent DB/storage states.
The plugin is powerful but complex (chunking, E2EE v2, real-time replication), and these intermittent issues pop up especially with intermittent connections or during heavy replication.
How to Recover the Missing File (“outfox.energy.md”)
Since you were working on it recently (energy tariff stuff from our chat), recovery should be straightforward:
Check Obsidian’s built-in File Recovery (core plugin — enable if not already):
Settings → Core plugins → File recovery
Open the snapshot viewer (or search in the vault for the file name).
Look for recent versions — snapshots are saved automatically on changes.
Look in .trash folder (Obsidian hides deleted files here):
In your vault folder → .trash (hidden folder).
Search for “outfox.energy.md” — restore from there if present.
Version history / snapshots in LiveSync:
If you have “Keep revision history” or similar enabled in LiveSync settings, check the plugin’s Hatch pane (ribbon icon or command palette → LiveSync: Hatch pane).
Use “Verify and repair all files” or “Recreate missing chunks for all files” — this often recovers or rebuilds missing data from chunks.
Remote DB check (if self-hosted CouchDB):
Access your CouchDB Fauxton interface (usually http://your-server:5984/_utils/).
Look in the database for documents related to “Usernames & Passwords/outfox.energy.md” (search by path).
If the entry exists remotely, use LiveSync’s “Fetch” or “Overwrite local from remote” (carefully — backup first!).
General backups:
If you have daily vault backups (recommended with sync plugins), restore from the last good one.
Or check if you pasted/copied the content elsewhere (e.g., our chat history has the tariff details — you could recreate the note quickly).
Preventing This in the Future
Pause LiveSync during poor/unstable internet — Use the pause button in the status bar.
Switch to periodic sync instead of real-time/live if your connection drops often (Settings → LiveSync → Sync mode → Periodic and on events).
Enable “Do not split chunks in the background” or other edge-case patches (in Patches section) — some users report this helps with intermittent errors.
Update the plugin — Check for the latest version (as of Jan 2026, v0.25.x+ has fixes for corruption/sync stability).
Consider alternatives for critical notes: Use Obsidian Sync (paid, more polished) or Git + remote repo for less fragile syncing.
Yes, with LiveSync version 0.25.36 on a self-hosted CouchDB setup, the behavior you’re seeing (file briefly appearing to vanish after an internet disconnect/reconnect, with replication spamming and errors like net::ERR_INTERNET_DISCONNECTED) is unfortunately a known class of edge-case issues in the plugin — though not always a “bug” per se, more a fragility in how it handles interrupted replications and conflict resolution.
Why This Happens (From Your Logs & Similar Reports)
-
When your internet drops (17:12 in logs), LiveSync can’t reach CouchDB → repeated fetch failures and “ERR_INTERNET_DISCONNECTED” spam (normal for the plugin’s aggressive checking).
-
On reconnect (17:26+), replication loops activate repeatedly (you see tons of “Replication activated” + “STORAGE → DB” for the same file).
-
In some cases, this loop causes a perceived mismatch between local storage (your actual files) and the DB index (what CouchDB thinks exists). LiveSync may then delete the local file to “sync” to what it believes is the authoritative remote state (e.g., missing chunks or a deletion marker from the interrupted cycle).
-
Your earlier log (14:45:03) shows exactly this: xxx ← STORAGE (deleted) Usernames & Passwords/outfox.energy.md — a deletion propagated or triggered during init/sync.
-
This is more common with:
-
Real-time/live replication mode.
-
Intermittent/unstable connections.
-
Files with recent local edits (like your tariff note).
-
Self-hosted CouchDB (some users report more issues vs. paid services like CouchDB on Fly.io or IBM Cloudant).
From GitHub issues and forum reports (up to early 2026):
-
Similar deletion/missing file problems after disconnects or replication interruptions appear in issues like #772 (download failures after initial sync), #693 (corrupted/missing large files post-sync), and older ones (#151 on deletion not propagating properly, or reverse cases where deletions don’t happen).
-
No major regression specifically in 0.25.36 release notes — that version focused on general stability, but these edge cases persist in the plugin’s chunk-based, real-time design.
-
Workarounds from users: Enabling certain patches (e.g., “Do not split chunks in the background” under Patches → Edge case addressing) helps prevent partial/corrupted writes during unstable syncs.
LiveSync is powerful but not as polished as Obsidian’s official Sync for handling flaky networks — deletions can propagate aggressively to resolve conflicts.