silverbulletmd
Page Changed Elsewhere, Reloading Error & Data Loss
I'm new to posting issues on GitHub, so please let me know if you need any additional information, etc. Apologies if this is too verbose.
Echoing some of the concerns in these resolved issues: https://github.com/silverbulletmd/silverbullet/issues/479 https://github.com/silverbulletmd/silverbullet/issues/603 https://github.com/silverbulletmd/silverbullet/issues/803
Context
- I am using Firefox (128.0.3) on Ubuntu (22.04.4 LTS).
- SilverBullet is being hosted on a Debian Server (12/Bookworm) within Docker (20.10.24). I started using SilverBullet about 13 days ago, using the "latest" tag.
- My SilverBullet space is being hosted on an NFS share via OpenMediaVault (OMV) virtual machine, which is a Debian-based NAS. These are all on the same physical server, but (Debian & OMV) are hosted on different VMs.
- SilverBullet is behind a reverse proxy (nginx). This is only being accessed from LAN.
Troubleshooting
I am receiving the "Page Changed Elsewhere, Reloading" error, which results in short term loss of the content I was typing up (similar to Issue 803). In one instance, SilverBullet freaked out and wiped the entire page. Also in Issue 803, I tried "space reindex" & "reload ui", but the issue still persists.
Per the conversations in Issue 603, I am using the default deployment of the Sync Mode. By this, I mean that I am not going "offline" and modifying local copies. I was attempting to have everything stay synchronized with the SilverBullet instance.
Bringing up some of the key items in Issue 479: The issue persists on FireFox & was not resolved when attempting to use Chromium. I did not see any of the issues regarding the hash conflicts.
Logs
My logs appear to be pretty sparse. I do notice a lot of repeated "Updated file list cache in background" messages. This appears to have been the case ever since I set up SilverBullet, and these logs were persistent prior to the issue being present. I would also like to note that I did not have any duplicate pages open in my browser. I saw a red notice, something about (paraphrased) "Reloading Again in 10 Seconds" but was not able to reproduce this reliably.
Most of the logs upon running SilverBullet again (to try and catch an errors at start-time):
docker logs silverbulletmd --follow --timestamps
2024-08-18T01:42:30.171179028Z Using KV as a database backend (/space/.silverbullet.db).
2024-08-18T01:42:30.171910574Z Going to start SilverBullet binding to 0.0.0.0:3000
2024-08-18T01:42:30.175006669Z Listening on http://localhost:3000/
2024-08-18T01:42:30.175407762Z SilverBullet is now running: http://localhost:3000
2024-08-18T01:42:30.799315334Z Using local disk as a storage backend: /space
2024-08-18T01:42:30.848682326Z Fetched uncached file list in 34.3833539999996 ms
2024-08-18T01:42:30.850840083Z Fetched uncached file list in 37.23829599999999 ms
2024-08-18T01:42:30.857039473Z Activated plug markdown
2024-08-18T01:42:30.860500300Z Activated plug tasks
2024-08-18T01:42:30.863593414Z Activated plug editor
2024-08-18T01:42:30.911181933Z Activated plug emoji
2024-08-18T01:42:30.918091397Z Activated plug template
2024-08-18T01:42:30.920132524Z Activated plug sync
2024-08-18T01:42:30.922117690Z Activated plug federation
2024-08-18T01:42:30.924231116Z Activated plug share
2024-08-18T01:42:30.926280303Z Activated plug search
2024-08-18T01:42:30.931936328Z Activated plug index
2024-08-18T01:42:30.934595159Z Activated plug plug-manager
2024-08-18T01:42:30.937617003Z Activated plug query
2024-08-18T01:42:30.939195186Z Booting up worker for index
2024-08-18T01:42:31.046872082Z Loaded 0 functions and 0 commands from space-script
2024-08-18T01:42:31.048461924Z Current space index version 6
2024-08-18T01:42:31.049595804Z Loading builtins attributes into index
2024-08-18T01:42:31.089882004Z Updated file list cache in background: 199 files found
2024-08-18T01:42:31.745587898Z Booted server with hostname 0.0.0.0
2024-08-18T01:42:31.748679412Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:42:31.754176087Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:42:31.756987998Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:42:31.758876684Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
...
2024-08-18T01:45:17.291756148Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:45:22.289505137Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:45:27.290674059Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:45:31.079114652Z Updated file list cache in background: 199 files found
2024-08-18T01:45:31.455027178Z Updated file list cache in background: 199 files found
2024-08-18T01:45:32.290119492Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:45:34.809866678Z Writing file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:45:35.018029303Z Updated file list cache in background: 199 files found
2024-08-18T01:45:39.735317511Z Writing file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:45:42.553941798Z Writing file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:45:43.270387179Z Updated file list cache in background: 199 files found
2024-08-18T01:45:59.393949918Z Writing file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:45:59.604571111Z Updated file list cache in background: 199 files found
2024-08-18T01:46:01.053587711Z alreadyFetching is on, skipping even triggering for fetchFileList.
2024-08-18T01:46:06.398821561Z Updated file list cache in background: 199 files found
2024-08-18T01:46:09.594505322Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:46:09.623711343Z Updated file list cache in background: 199 files found
2024-08-18T01:46:12.310927756Z Requested file Library/Core/Snippet/note-admonition.md
2024-08-18T01:46:16.505051320Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:46:18.037248616Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:46:18.040713834Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:46:18.043395776Z Writing file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:46:18.362542191Z Updated file list cache in background: 199 files found
2024-08-18T01:46:19.086674661Z Requested file Library/Core/Widget/Table of Contents.md
2024-08-18T01:46:19.089887037Z Requested file Library/Core/Widget/Linked Mentions.md
2024-08-18T01:46:19.095178650Z Requested file Library/Core/Widget/Linked Mentions.md
2024-08-18T01:46:19.541703786Z Requested file Library/Core/Widget/Table of Contents.md
2024-08-18T01:46:19.547052888Z Requested file Library/Core/Widget/Linked Tasks.md
2024-08-18T01:46:19.550304853Z Requested file Library/Core/Widget/Table of Contents.md
2024-08-18T01:46:19.553761211Z Requested file Library/Core/Widget/Linked Mentions.md
2024-08-18T01:46:19.726389582Z Requested file Library/Core/Widget/Linked Tasks.md
2024-08-18T01:46:19.929350184Z Requested file Library/Core/Widget/Linked Tasks.md
2024-08-18T01:46:29.519987741Z Updated file list cache in background: 199 files found
2024-08-18T01:46:29.996271682Z Writing file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:46:30.228926869Z Updated file list cache in background: 199 files found
2024-08-18T01:46:31.057046565Z alreadyFetching is on, skipping even triggering for fetchFileList.
2024-08-18T01:46:31.288294291Z Updated file list cache in background: 199 files found
2024-08-18T01:46:32.290612861Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:46:37.277894572Z Writing file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:46:40.368629008Z alreadyFetching is on, skipping even triggering for fetchFileList.
2024-08-18T01:46:40.740112967Z Updated file list cache in background: 199 files found
2024-08-18T01:46:40.771148903Z Fetched uncached file list in 74.00124700000742 ms
2024-08-18T01:46:41.748316694Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:46:41.752392396Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:46:41.757444456Z Writing file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:46:42.010700447Z Updated file list cache in background: 199 files found
2024-08-18T01:46:42.324475337Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:46:42.334341986Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:46:52.342944614Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
2024-08-18T01:46:52.346411102Z Requested file HomeLab/Wiki/Misc/Backup/Borg_Backup.md
Closing Comments
My assumption is that my NAS is probably not keeping time well enough, as you said, Zef, in other issues. However, if my issue is not local to me, I would be remiss to keep this issue to myself if it could help somebody else out or help to improve the project. I've been enjoying SilverBullet a lot since I stood it up. All your hard work on this project is very appreciated!
I also started experiencing exactly this issue. I'm using a digitalocean droplet for running silverbullet.
I'm also experiencing this issue whilst running in a docker container on Unraid. The data partition is running direct on the Unraid array and is not mounted via NFS, SMB etc...
Just chiming in with my experience getting this error. I found this issue from the SB community site. I'm seeing a lot of reports from people using Synology or other NAS. I'm running this on a VPS running Debian 12, and my space is synced using Syncthing.
So, I thought it could have something to do with my Syncthing setup at first. However, the error still happens even after I stop syncing with Syncthing. I feeel that Syncthing being the cause would’ve been weird, because monitoring the modification dates, they seemed correct.
I get this in the browser console of the PWA:
client.ts:597 Page changed elsewhere, reloading. Old hash undefined new hash 1737386664925
16:24:37.350 client.ts:603 Last save timestamp 1737386664877 now 1737386677350
Also getting multiple lines of:
alreadyFetching is on, skipping even triggering for fetchFileList.
Not sure if the undefined hash or alreadyFetching is a related or expected behavior here. I’m also seeing increased CPU usage after the file is saved for about 8-10 seconds, from multiple deno run -A --unstable-kv --unstable-worker-options /silverbullet.js processes, after which the “page change elsewhere” message appears.
Interestingly, I seem to have no issues with the index file, but I can consistently reproduce this another file. The index file is 20 lines, while the other file is 931 lines.
I believe that the "page changed elsewhere" error, at least in my case, only happens on large markdown files with lots of links, tasks, etc. The error does not seem to occur on very small files. CPU spins up for about 10 seconds with deno processes, and after this, the error happens. This is on a VPS with an AMD EPYC-Rome, 4 vCPU's at 2Ghz and 8GB of RAM. Is 8-10 seconds of saving time expected for a ~1000 line Markdown file with many tasks, links, code blocks, etc.?
client.ts:668 Saving page TODO
evented_space_primitives.ts:56 alreadyFetching is on, skipping even triggering for fetchFileList.
08:36:36.252 client.ts:597 Page changed elsewhere, reloading. Old hash undefined new hash 1737444984102
08:36:36.252 client.ts:603 Last save timestamp 1737444984402 now 1737444996252
08:36:36.253 client.ts:968 Reloading page
I am noticing that this is occurring more frequently on pages with a lot of checkboxes. I have 341 checkboxes my most notorious file. Another page where it has begun creeping in has 110 checkboxes rendered. It doesn't seem prevalent below ~110ish checkboxes.
I am noticing that this is occurring more frequently on pages with a lot of checkboxes.
Oh, absolutely. On the page where I noticed the issue, I have over 500 checkboxes, haha. I should get more organized, obviously, and archive/delete some of that stuff. But I'm still not sure if it should take 8 seconds to reindex this page and maybe some optimization could be possible.
On the contrary, your 500-checkbox page helps figure out what's causing it 😅
The way I see it, there are multiple issues that are affecting this:
- Something about many-checkbox pages takes a long time to be processed
- SilverBullet allows us to edit pages during processing (intentionally or otherwise), and seems to realize this happened when it's done
2 is the more severe problem, as it can lead to data loss. 1 is annoying, but 2 "hides" it (unless you tap the wrong thing). I think this might be related to https://github.com/silverbulletmd/silverbullet/issues/1093; in both cases, SilverBullet prefers to "led you edit while stuff is going on in the background" rather than telling you "hang on I'm doing stuff".
- SilverBullet allows us to edit pages during processing (intentionally or otherwise), and seems to realize this happened when it's done
I'm not sure that this is happening in my case. I tested with just hitting enter on the big page and, after 10 seconds, it happens. I cannot imagine what other thing might have edited it in the meantime. I certainly didn't.
11:20:56.941 client.ts:668 Saving page TODO
11:20:57.015 evented_space_primitives.ts:56 alreadyFetching is on, skipping even triggering for fetchFileList.
11:21:07.778 client.ts:597 Page changed elsewhere, reloading. Old hash undefined new hash 1737714057021
11:21:07.778 client.ts:603 Last save timestamp 1737714056941 now 1737714067778
11:21:07.779 client.ts:968 Reloading page
I'm not up to snuff on typescript. Would something such as adding an event listener for a user's input delaying the save event work for this and/or #1093? I'm basing this idea off the code in web/client.ts or web/sync_service.ts and thinking something like this:
// A function to handle the saving process
function saveChanges() {
console.log("Changes are being saved...");
// Implement saving logic here
}
// Setup a debounce mechanism to delay the execution of the final save operation
let savingTimeout: number | undefined;
document.addEventListener('input', (event: Event) => {
if (!(event.target instanceof HTMLInputElement)) return;
// Clear the previous timeout, if any, to reset the saving delay
if (savingTimeout !== undefined) {
clearTimeout(savingTimeout);
savingTimeout = undefined;
}
// Set a new timeout to save changes after 2 seconds of no input
savingTimeout = setTimeout(() => {
saveChanges();
savingTimeout = undefined;
}, 2000);
});
I'm quite positive this doesn't fit SB's construction but hoping it illustrates my thought process.