but what happens if at runtime the user specifies a teleporter version that doesn't match up with the ABI bindings that the cli was built with? likely a silent/mysterious failure, i'd guess.
this is a bit of a chicken and egg problem: the cli needs those ABI bindings at build time, but the teleporter version can be specified at run time. how can we resolve this discrepancy?
This may seem like an obscure edge case at this time, but the Interop team is looking to utilize the avalanche-cli in our development workflow for teleporter (see https://github.com/ava-labs/avalanche-cli/issues/1921) and if/when that happens this could become a blocker for that.
i was just looking into whether there might be any issue with ABI mismatches, and I think i found one.
the source for the cli's teleporter msg command imports github.com/ava-labs/teleporter/abi-bindings/go/Teleporter/TeleporterMessenger.
but what happens if at runtime the user specifies a teleporter version that doesn't match up with the ABI bindings that the cli was built with? likely a silent/mysterious failure, i'd guess.
this is a bit of a chicken and egg problem: the cli needs those ABI bindings at build time, but the teleporter version can be specified at run time. how can we resolve this discrepancy?
This may seem like an obscure edge case at this time, but the Interop team is looking to utilize the avalanche-cli in our development workflow for teleporter (see https://github.com/ava-labs/avalanche-cli/issues/1921) and if/when that happens this could become a blocker for that.