Fix Liquid database migration

[natsoni]

This PR fixes the broken database migration scheme 75 by adding a network check in the migration before truncating bitcoin specific tables.

[wiz]

why didn't this issue reproduce in production?

[natsoni]

why didn't this issue reproduce in production?

It looks like database migration to version 75 was modified on April 4th, about 2 weeks after it got added to master on March 13th. These lines were added:

await this.$executeQuery('TRUNCATE hashrates');
await this.$executeQuery('TRUNCATE difficulty_adjustments');
await this.$executeQuery(`UPDATE state SET string = NULL WHERE name = 'pools_json_sha'`);

Maybe prod got upgraded to version 75 before the migration being updated with the above changes that broke Liquid?

[wiz]

Yeah it might be a better idea to simply revert that commit and add a new migration for the truncate

[wiz]

Also there shouldn't be more than one SQL query per migration in case it fails

[wiz]

Let's revert the breaking commit and instead add a few new migrations that do the same thing, with the correct network check if necessary

[natsoni]

IIRC the breaking commit was added to fix a production bug with the hashrates table that is now fixed. @nymkappa can you confirm? If yes, only reverting the commit should be enough?

[softsimon]

tested ACK @ [ea1e269]

I can confirm my current Liquid database wasn't affected by this bug. I had to try a clean database, and it reproduces.

[wiz]

TRUNCATE'ing the hashrates and difficulty adjustments is just a re-index, just move those to their own new migrations and it will be fine

[wiz]

utACK

[wiz]

Will merge after manually bumping prod servers to 81 to avoid the re-indexing downtime