MASQ-Project
Activate CORES Migration
The CORES migration machinery in the Node is written, working, and unit-tested, but not yet complete. Two things remain to be done.
First, the existing architecture is inefficient. MigrationStep::migrate() returns a Result<Vec<u8>>, which means it must perform an unnecessary serialization step after its conversion; then this serialization must be deserialized by the caller. MigrationStep and the structure it fits into should be simplified to eliminate this extra serialization/deserialization cycle. This will require more generic-type manipulation than is currently done by the code; it's possible that early versions of Rust were incapable of this, and that's why the inefficiency was tolerated.
Second, each of these VersionedData structs must have a migration written for it (probably using the migrate_value! macro) that can migrate data from the future backward into the _0v1 versions. Without these migrations, the entire migration subsystem is useless.
-
DnsResolveFailure_0v1 -
ClientRequestPayload_0v1 -
ClientResponsePayload_0v1 -
Gossip_0v1 -
GossipFailure_0v1 -
NodeRecordInner_0v1
Can consider a type of log that will instruct user that gossip version is not compatible Would need to determine if this is feasible and when a Node determines it's gossip is out of date and would never encounter older Nodes to connect to
