Project is corrupt\n(Unable to work with the blockfiles) error may not have to be fatal

[JohnColket]

A forum user was unable to open their project with the following error:
Project is corrupt\n(Unable to work with the blockfiles)
"type": "Error_Opening_Project",
"value": "Project is corrupt\n(Unable to work with the blockfiles)",
"sqlite3.query": "DELETE FROM sampleblocks WHERE NOT inset(blockid);",
"sqlite3.rc": "11",
See: https://forum.audacityteam.org/viewtopic.php?f=46&t=120572

So this error looks pretty fatal; however this error (11=corrupt database) only occurs while audacity is trying to DELETE orphan blocks. Simply bypassing this error allows the file to load, allowing the tracks can be copied to another database.

[petersampsonaudacity]

Assigned P2 as this blocks users from accessing their valuable project data - and causes big support issues.

[JohnColket]

Project produces same/similar error in Audacity 3.0.4 also w/recent alpha

[crsib]

Database corruption is a serious issue, but fixing every possible case will likely require significant changes to the persistence layer and file format itself.

There are different cases that should be handled separately:

1. Project file blob is unreadable. I'm not sure if this problem is fixable at all. This is a design choice largely, not simply a bug.
2. Samples are "missing". This case requires lots of SQLite magic to be implemented. Generally speaking - some samples won't be recoverable anyway, so we need to handle those cases somehow as well.
3. General index corruptions. This specific case looks like it.

For cases 2 and 3 we need as many corrupt projects readily available as possible because this issue is totally random and not reproducible. For this specific case, I think that we do not have the project in question, and failure in this specific query is new to mee