target overrides should check whether the override chain has the same metadata

[ryanleecode]

Based on my understanding when specifying a target in nets.ts, it only swaps out the connection and not the "chain rune".. i.e. westend does not become westendDev. So whatever extrinsics are created will use the original metadata regardless of what the metadata is on the target chain. If there's a runtime upgrade on the prod chain and you don't bump the version in bins, then your extrinsics can seemingly fail, without it being obvious to the end user why its failing.

For example given this nets config:

import { bins, net } from "capi/nets"

const bin = bins({
  polkadot: ["polkadot-fast", "v0.9.43"],
})

export const westendDev = net.dev({
  bin: bin.polkadot,
  chain: "westend-dev",
})

export const westend = net.ws({
  url: "wss://westend-rpc.polkadot.io/",
  targets: { dev: westendDev },
})

Had i used anything lower than v0.9.43, extrinsics would fail with:

Unhandled promise rejection Unhandled {
  value: ServerError: Invalid Transaction
    at RunMap.fn (http://localhost:1234/index.b7a05eb9.js:24333:36)
    at RunMap._evaluate (http://localhost:1234/index.b7a05eb9.js:23114:44)
    from execution of the ValueRune instantiated
        at new Rune (http://localhost:1234/index.b7a05eb9.js:22321:23)
        at new ValueRune (http://localhost:1234/index.b7a05eb9.js:22997:1)
        at Function.new (http://localhost:1234/index.b7a05eb9.js:22999:16)
        at ValueRune.map (http://localhost:1234/index.b7a05eb9.js:23002:29)
        at ConnectionRune.subscribe (http://localhost:1234/index.b7a05eb9.js:24332:177)
        at RunMap.fn (http://localhost:1234/index.b7a05eb9.js:24725:60)
        at RunMap._evaluate (http://localhost:1234/index.b7a05eb9.js:23114:44)
        from execution of the ValueRune instantiated
            at new Rune (http://localhost:1234/index.b7a05eb9.js:22321:23)
            at new ValueRune (http://localhost:1234/index.b7a05eb9.js:22997:1)
            at Function.new (http://localhost:1234/index.b7a05eb9.js:22999:16)
            at ValueRune.map (http://localhost:1234/index.b7a05eb9.js:23002:29)
            at SignedExtrinsicRune.sent (http://localhost:1234/index.b7a05eb9.js:24725:27)
            at transferDev (http://localhost:1234/index.b7a05eb9.js:653:13)

Similar to #961, #1052.

Ideally Capi should have a check in place to make sure the target chain is compatible with the prod chain.

[ryanleecode]

925 also mentioned

This would also open the door for us to validate prod-dev chain feature parity. We could produce console warnings about inconsistencies between the default and target-listed metadata.

so this issue should be seen as a follow up

[harrysolovay]

Currently, specifying --target does not actually touch the codegen; it passes an env var, which is picked up by the detectConnect util. Although we could swap out the served chain rune, this could be treacherous for a few reasons:

• cached code would frequently change / become invalid
• extra codegen (for every target)
• in Node projects, we'd need to write to chains' respective node modules (which could be stored in different places depending on the package manager)

Would warnings about incompatibilities suffice? Not sure we should try to do anything too fancy with --target.

[ryanleecode]

Warnings seem like the best option 👍