Probably less of a bug report than a suggested documentation change. In development/testing of an RSS feed reader (on a stock Raspberry Pi install, if that helps any), I somehow managed to corrupt the DB, and for the first time ever I found myself on the recovery page.

I got a bit worried when this happened:

SQLite version 3.40.1 2022-12-28 14:03:47
Enter ".help" for usage hints.
sqlite> .recover
BEGIN;
PRAGMA writable_schema = on;
PRAGMA encoding = 'UTF-8';
PRAGMA page_size = '4096';
PRAGMA auto_vacuum = '0';
PRAGMA user_version = '0';
PRAGMA application_id = '0';
sql error: SQL logic error (1)
sqlite> 

Looked like it was really stuffed, so I figured there was no harm in poking around further. Both .tables and .schema gave normal enough results. I started doing a few basic select queries, and many of them returned results that looked perfectly fine! I don't know what expected behavior is for a corrupt database, but things seemed to be far better than .recover had lead me to believe.

So I essentially went through all the ways I could see documented to copy a DB. Many of them failed with errors, but two "worked". Doing a .dump gave me a file that appeared to be mostly complete, although the last line is:

ROLLBACK; -- due to errors

I never bothered further with that, because the other command was .clone, which resulted in a DB that appears to be entirely functional, and I've been using it without problem for the last couple days. The only thing lost appears to be a couple of the feed items, where a count from the corrupt DB gave 1306 whereas the clone gave 1304.

If the bad DB would be at all useful to examine, let me know. It's only about 10MB, and the feed data it contains is nothing particularly private. Like I said, I don't know that .recover is doing anything wrong that needs to be debugged, but the recovery page really would benefit from a "try all the things" message.