Long running dashboard crashes

[DaveMBush]

First, I love this. It is exactly what I was looking for. However (there's always a however, right?)...

When I leave the dashboard up for a long time, like all day, over 6 hours, eventually I get a message from my browser saying "there is a problem with your app" with a "refresh" button. When I hard refresh, none of the filter panels show. Like it has lost all its information. I haven't done a lot of debugging but it seems it is having trouble accessing IndexDB like maybe it is being opened repeatedly without closing and running out of handles to open IndexDb. The only way I am able to get back to usable is to reboot my computer.

I'm using the dev build locally and pulled it down a couple days ago because that was easier than installing a server locally. I've used it on multiple browsers including Edge and the Chromium browser that runs inside RamBox. Both have had this recurring issue.

[pvcnt]

Hi @DaveMBush, thanks for using this software! It's a behaviour that I have been encountering seemingly randomly in the past, but I always assumed it was because of I was messing up with my environment. I also rarely leave the tab for Mergeable open, even though it should be a supported (if not recommended) workflow.

I tried leaving the https://mergeable.pages.dev/ tab for a while (and forgot about it, and my laptop went to sleep), and I observed the following (Chrome on macOS):

• The refresh background job stopped.
• When coming back screen is blank, and "Storage" tab in Chrome Developer Tools is even empty.
• After another while (and forgetting about my tab being open, etc.), it seems that data is showing again.
• Doing a hard refresh seemingly erased the entire IndexedDB (which may be the expected behaviour?).
• After a hard refresh, the IndexedDB seems to be permanently done and I cannot interact anymore with the app.

It looks a bit hectic and random to me, and I did not manage to reproduce exactly this flow. I definitely needs to investigate this, as it is a roadblock for many use cases...

[DaveMBush]

I bet if you reboot your computer IndexDb comes back with the content. That's been my experience. I'm pretty sure it is a file handle thing (under the hood).

I did take a look at the code and see you are using dixie, which I've used in the past. given what you've told me about your experience, the next place I would look is that SharedWorker (or is is a WebWorker? I don't remember.)

A dead worker doesn't explain my situation where nothing went to sleep 🤷

BTW, over the weekend I turned this into an electron app where electron has its own web server that serves the files 🙂

[DaveMBush]

Thinking about this more. Is there some reason you are storing the last refresh times in IndexDb. Maybe if you stored that in memory, or session variables instead that would cut down on the traffic.

The other thought, which I admit is a hack, is to explicitly close IndexDb after each access, just make sure autoOpen is set in the constructor https://dexie.org/docs/Dexie/[Dexie.close()](https://dexie.org/docs/Dexie/Dexie.close())

Even if that didn't fix it, we'd know more.

[pvcnt]

Last refresh time is stored in order to know what to do when a new tab is open (and avoid triggering a background process if not needed). Not sure to follow how that would help to store it elsewhere?

It's highly possible I'm not use Dexie correctly, big projects are reported as using it and it seems to work for them. But I also see projects (e.g., Excalidraw) sticking with plain old local storage, which seems more reliable than IndexedDB at times.

[DaveMBush]

That thought about storing times somewhere else was mosly thinking about cutting down the calls to Dixie.

Dixie is pretty solid. I've used it as a mechanism for caching server side on a rather large project with 1000 people using it. We had other issues, but they had more to do with our code that was accessing it than anything fundamentally wrong with Dixie. And RxDB https://rxdb.info/ seems to be using it as a preferred means to store things in index.db. So I think it is safe to rule out issues with it.

LocalStorage is fine if you don't need the performance or need the size.

I looked at your code and from what I can see, it looks fine. I haven't used liveSync though. I'm also not sure about how you are using it inside of React. My experience with it is with Angular. Maybe something with a hook, or re-rendering? 🤷