[F-OBrien]

Why

The resync of #383 and #382 from genesis on testnet and mainnet turned up three problems that aren't in the expected differences:

1. Testnet: 19 onboarded accounts lost their identity on their first fee. An authorization creates its target's Account as a bare Unlinked row (fix!: 🐛 match the chain's state where upgrades, silent calls and decodings left the index wrong #383). When the target was later onboarded, nothing linked that row until DidCreated. So the Endowed before it, in the same block, was recorded with no identity, and those identities and portfolios started at DidCreated rather than at the block's first event.
2. Testnet: 23 instructions' failure reason changed from run to run. These are the 23 that failed at 10,036,148, the first block on 6.0. Some runs read DeprecatedCallOnV2Instruction, which is 5.4's name for error 37/0x22; others read 6.0's FailedToReleaseLockOrTransferAssets.
3. Both chains kept 2 fork blocks each after reaching head. On mainnet, each one's fee went to the fork's block author, which is the 4 head check-state differences.

What

Link a bare account when its key record names it

getOrCreateAccount returned any existing row as it was. Now an existing row that is Unlinked with no identity reads the key record, as a missing row does, and is linked through upsertAccount when the chain names the address as a key. The row keeps its createdEventId.

The key record is still read at most once per address per block, and testnet has only 711 such rows. This also covers an address that held POLYX before it was onboarded.

Name a dispatch error from the runtime that decoded it

The dictionary starts most specs up to 300 blocks late. On those blocks the node builds the mappings' api with the previous runtime's metadata, so api.registry.findMetaError can name another runtime's error.

The event itself is decoded at its own block's runtime: the node fetches events with system.events.at(hash). So getErrorDetails now uses the codec's own registry, and the two pre-6.0 silent-failure paths pass theirs along.

The dictionary's late starts are fixed in PolymeshAssociation/polymesh-subquery-dictionary#8, together with a one-off correction of its stored rows. This change makes error names right whatever the dictionary says.

Rewind fork blocks

The fork blocks were kept by @subql/node-core 19.0.0, which @subql/node 6.4.6 pins:

• it never checks an unfinalized block's parent hash;
• it compares only the highest stored block at or below finality with the chain;
• so a fork block followed by a canonical one is never rewound.

19.2.0 added the parent-hash check (subquery/subql#3016), but it exits on most of those forks instead of rewinding them. On testnet that happened minutes after reaching head. The fix is upstream in subquery/subql#3052. Until a @subql/node release includes it, the image:

• Replaces node-core with 19.3.1 in the upstream image's node_modules, which is the copy the node actually runs. 19.3.1 also fixes a SQL injection in dynamic datasources (fix(node-core): sql injection in dynamic datasource appending via unescaped json serialization subquery/subql#3031).
• Applies docker/patch-node-core.js, the same change as #3052 against 19.3.1's compiled code. The build fails if that code isn't exactly what the patch replaces.
• Pins node-core to 19.3.1 in resolutions, so local runs and tests use the same version as the image.

Verification

• Unit tests: 3,798 pass, with new tests for the first two fixes. Lint, check-strict-null and yarn build pass.
• The failure reason: at 10,036,148, the event's own registry is 6.0's and names the error FailedToReleaseLockOrTransferAssets; the registry of the block before names it DeprecatedCallOnV2Instruction.
• The image, against testnet head:
  • 19.3.1 unpatched: the node exited at 26,457,518 on Expect best header and checking header to be at the same height. On restart it rewound the fork block 26,457,517.
  • 19.3.1 patched: the node rewound a fork at 26,458,389 to 26,458,391 without exiting. Afterwards its unfinalized blocks all matched the canonical chain.
• Full resync: staging, testnet and mainnet are next.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[prashantasdeveloper]

/fast-forward