Unexpected difference in fileset version failure: best action to take?

Sometimes one of my jobs run into this error. I’ve read some threads where it is siggested to delete the failed version. But every time it has happened to me, just after the version deletion I encountered the same error for the previous version, and I was forced to delete /all/ other previous versions until the first (0) one. So, since this was very annoying and time expensive, the last time I tried a different thing: recreate the database (delete and repair button), and this solved the problem as well.
Therefore I ask: the two different actions (delete previous versions and recreate the database) has the same consequences, or is there some reason to prefer the former over the latter?
Thanks for all your clarifications.

Obviously deleting versions deletes versions, so has that drawback (in addition to time and work).

Recreating the database loses your logs (which are in the database) and is sometimes quite slow.
This is especially likely for damaged destinations, or very large backups done at default blocksize,
which is good for around 100 GB before database operations start to slow due to too many blocks.
In addition to that, a failing recreate may download your entire backup, so what’s the speed there?

Apparently your run worked well enough, so good. If you ever test-recreate, you can also save old
database in case the Recreate doesn’t work nicely and you need old one for analysis or running…

Duplicati has been getting better (but not perfect) at not failing Recreate over the years, so deleting individual versions used to be something done in the hope of avoiding a potentially messy situation. (round up to for wide use):

Fixed data corruption caused by compacting, thanks @ts678 and @warwickmm (round up to for wide use):

Fixed some cases where an interrupted backup could cause database corruption, thanks @seantempleton

It would be nice to figure out why, and you could probably try to collect some information on causes.