[BUG] discarded page must be writable Exception

[sharad-emydex]

Version
5.0.20
.NET Framework : 4.8
Litedb used within a Windows Service.

Describe the bug
I see this discarded page must be writable Exception fixed by this PR Update MemoryCache. However, we recently encountered two instances of this exception in our production environment in the last 6 months with the latest version of LiteDb.

It is totally random and there is no way to handle this exception. The service crashes and restarts again and the data is lost. The stack trace does not provide much information.

Code to Reproduce
Unable to reproduce locally, service keeps running and unexpectedly at some point we get this exception

Expected behavior
LiteDb services should be available

Screenshots/Stacktrace

Additional context
Is there any way to handle this exception or prevent the service from crashing? This service is critical for our factory operation and even few minutes downtime causes havoc in the factory and the customer has to revert to manual process. So, any help would be greatly appreciated.

[sharad-emydex]

Has anyone got any fix or workaround for this issue ? We are really struggling with this as the service crashes when this exception occurs.

[sharad-emydex]

@mbdavid apologies for the tag, do you have any suggestions or workarounds? This code is in production at the moment, and customers are feeling anxious that we use open source LiteDb and haven't been able to provide them with an RCA. Attaching an investigation report which may be of some help

dblite_log.txt

[SupermindPT]

It seems either the maintainers are too busy or jumped ship. There has been no new releases since 5th July 2024, even though there has been some commits to this repos since then. You could fork the repos to catch these new commits but nothing guarantees the bugs are fixed.

I am starting to question our decision to go with LiteDB for big production apps because there are simply too many errors that we did not catch up early on. I suggest you consider migrating your database to SQLite, that is what we are considering.

As for the error itself, try to optimize your database indexes, it could be related to some malformed or invalid index.

[JKamsker]

Hi @sharad-emydex - thanks for raising this and sharing the logs, they helped pin down the root cause.

The discarded page must be writable crash comes from a race during long-running transactions. When Safepoint() flushes dirty pages, the page buffers are moved from writable to readable in the cache. If an exception happens after that flush but before commit, Rollback() still tries to discard those pages as if they were writable, which triggers the assertion.

I’ve patched this in LiteDB so that rollback and dispose now filter both dirty and clean pages, and only pass buffers that are still writable into the discard path. This keeps the internal safety check intact while preventing safepoint-flushed pages from causing a crash. I also added regression tests that simulate the exact safepoint → exception → rollback scenario, and the tests now pass consistently.

What this means in practice

• With the fix, Rollback() no longer throws when safepoint has already transitioned pages to readable.

• The crash you saw in production should not happen again once you’re on the patched build.

• The follow-on “file is being used by another process” messages are a separate effect of the crash: another process (or a restarted service instance, or sometimes antivirus/backup software) was trying to open the database while handles from the crashed process were still live. Since LiteDB only supports single-process access, it’s worth double-checking that:

  • no second process (including AV/backup) is touching the .db file,
  • the service retries with a short backoff after a crash/restart, so the OS can release file handles.

That combination - the code fix plus some operational guardrails - should eliminate both the assertion crash and the “file in use” errors you’ve been seeing.