Investigate origin and severity of ExternalizedNHMismatch error

[ebma]

Some parts of our integration tests started failing quite frequently with the following error:

thread 'test_execute_open_requests_succeeds' panicked at 'Failed to execute issue: SubxtRuntimeError(Runtime(Module(ModuleError { pallet: "StellarRelay", error: "ExternalizedNHMismatch", description: [], error_data: ModuleErrorData { pallet_index: 10, error: [7, 0, 0, 0] } })))', clients/vault/tests/vault_integration_tests.rs:134:10

see eg, this and this CI job.
Since it's not always the same test function that fails, we can assume that this error only happens occasionally.

However, we should try to identify how likely this error occurs and why. It might be that the underlying problem is quite severe and we should make sure that the vault is able to successfully provide proof for an issue/redeem request to the stellar-relay pallet all the time, now that we fixed the archive problem.

[ebma]

@pendulum-chain/product I created this bug ticket and assigned it to an epic. Let me know if you have questions and need more context. Feel free to assign people to the planning poker.

[annatekl]

Hey team! Please add your planning poker estimate with Zenhub @ashneverdawn @ebma @TorstenStueber

[ebma]

Please add your planning poker estimate with Zenhub @b-yap

[TorstenStueber]

Any clue what ExternalizedNHMismatch means? Has it something to do with externalize messages?

[ebma]

IIRC the error is thrown if not all messages that we use in the proof are using the same n.h value.

[TorstenStueber]

Oh, that is unexpected. I would like to see such an example where this assumption does not hold (for whoever picks up this ticket).

[ebma]

@pendulum-chain/product investigating this problem is very important and should have a very high priority in the backlog.

[prayagd]

@ebma Sure, moved it to the ready column on the top