`failed to open cache db: timeout`

[9999years]

Describe the bug

It is possible to get the treefmt cache database into a bad state where all treefmt operations fail, including treefmt --clear-cache!

To Reproduce

We do not have a reproducer available, but we will update this ticket if we find one.

This issue manifests with errors instead of formatting:

$ treefmt
Error: failed to open cache: failed to open cache db: timeout
$ treefmt --clear-cache
Error: failed to open cache: failed to open cache db: timeout

Expected behavior

When treefmt is run, it should work instead of crashing.

If the cache database is corrupted, it should be deleted instead of crashing treefmt.

treefmt --clear-cache should never fail because the cache database is unavailable; the database should be deleted, not opened.

System information

macOS, treefmt v2.2.1

Additional context

The issue was resolved by manually deleting ~/Library/Caches/treefmt. This was challenging because the cache directory is not documented, and the source code implies it lives in $XDG_CACHE_HOME, which is not how treefmt behaves on macOS.

[jfly]

Thanks for the report, @9999years!

We consider it to be a bug if it takes more than 1 second for treefmt to open its boltdb cache. That's sort of tracked by #478. Unfortunately, we don't have any information on how this happens. Is it possible you had a hung treefmt process running somewhere else?

I propose a couple of changes.

1. Give people some information so they can better report this issue:

$ treefmt --clear-cache
Error: failed to open cache: failed to open cache db: timeout

Yikes, that shouldn't happen. <instructions about how to collect some useful information and report this to us>

To get things working again, run `treefmt --clear-cache --force`, but please report the issue so we can fix it!

2. As implied by the message above: change --clear-cache to take an optional --force that works even if the cache is locked.

Alternatively, we get rid of all this, maybe the filesystem is a good enough db for what we're doing. Curious what @brianmcgee thinks.

[9999years]

Yeah, I do wonder if there was a hung process running somewhere. It's a shame that the only information we get is "the db is already locked" and not what is locking the db.

[brianmcgee]

Most likely, you had a zombie process somewhere holding the DB open.

I've made a fix with #593, which does as you suggested and force-deletes the db file. Honestly, I don't know why we were doing it the other way by first opening the db 🤷

I've also made it clearer in the error which DB file it cannot open.