migration: scope key migration to stores

[tychoish]

The original migration script assumed that there was essentially one store and that keys with any prefix could appear in any store, which while not apparent from the code, is not true. As a result the initial implementation of the migration was too flexible and would attempt to faithfully migrate code with any prefix in any collection.

The challenge with this approach, is that some keys can appear to to have prefixes that don't apply. In particularly the indexed data could appear to be evidence or another key, and be migrated into the (relative) unknown, resulting in apparent data loss. The inverse, would be much less likely but theoretically possible.

Thankfully, if we only attempt to migrate keys in stores with the corresponding prefix. This change restructures the migration so that we pass the name of the store into the migration function, and then define migrations with store names so we can correlate and scope migrations appropriately.

Additional follow on work will integrate migrations into database constructors as part of node construction.

Addresses: #8889

[cmwaters]

@tychoish can you add a description of the PR and possibly link the reference issue (which I believe is the automating upgrades one)

[tychoish]

@tychoish can you add a description of the PR and possibly link the reference issue (which I believe is the automating upgrades one)

Done!

[williambanfield]

Thankfully, if we only attempt to migrate keys in stores with the corresponding prefix.

Does this fix allow the problem of key migration collisions to completely go away?

[tychoish]

Does this fix allow the problem of key migration collisions to completely go away?

I believe so. The caveats/risks of key migration remain:

• Particularly of the transaction index and indexed events it's possible that the migration could be non-idempotent. This is very slim, but proving idempotentcy is hard.
• There could still be bugs in the migration, which could render some data being unreachable, likely in a way that could be pretty silent. This is not a new risk, and proving that it's not there is hard.

There aren't a case of systemic migration bugs that are dependent on the input data, which was the case before.

While this change does not automate the run of the migration script, doing so is still not without costs:

• running the migration script for a table before opening that table takes time, and we don't have a good way right now of storing "we're done with the migration" for easy nooping.
• idempotentcy would be nicer to be more sure of.

[cmwaters]

👍

[cmwaters]

running the migration script for a table before opening that table takes time, and we don't have a good way right now of storing "we're done with the migration" for easy nooping.

This would be nice to achieve for automatic migrations

[tychoish]

running the migration script for a table before opening that table takes time, and we don't have a good way right now of storing "we're done with the migration" for easy nooping.

This would be nice to achieve for automatic migrations

Definitely. Shouldn't block this PR, and maybe would be a good ramping project for someone.