test: Add packet test for Axon

[jjyr]

Description

Add new ibc test TransferTest.
This test only works with Axon chains. (CKB should be added after the contract refactory).

This test sends a IBC call from chain A to chain B, then checks there is a SendPacket event happend on chain A and a ReceivePacket event happend on chain B.

[ashuralyk]

This test only works with Axon chains. (CKB should be added after the contract refactory)

this means to prevent the duplicate work on refactoring test or just cannot adapt for current CKB implementation?

[jjyr]

This test only works with Axon chains. (CKB should be added after the contract refactory)

this means to prevent the duplicate work on refactoring test or just cannot adapt for current CKB implementation?

1. We need to implement the CKB version MockTransfer.
2. We need to implement the equavalent version sendTransfer method for CKB contract.
3. We need refactoring the test to support CKB chains.

[jjyr]

@ashuralyk @blckngm

The new commits using ChainDriver#ibc_token_transfer to transfer ICS tokens, please review the updated PR.

1. Delete a lot of code from TransferTest.
2. Please check the implementation of ibc_token_transfer function, we could implement CKB in the same way.

[ashuralyk]

the event log doubled like this:

this is because the CI runs two test cases at the same time and we cannot distinguish what errors belong to which one.

NOTE: passed CI tests are not really passed because errors are printed but tests result in success. this problem can be found in our previous merged PRs as well like here.

[jjyr]

NOTE: passed CI tests are not really passed because errors are printed but tests result in success. this problem can be found in our previous merged PRs as well like here.

Not ture, of course these CI are passed, the error messages are raised from monitor thread, becaused we haven't correctly implement the ibc4ckb interfaces.

I have already clarified this known issue from an early PR: #308 (comment)

Known issues:
there are some error output of ibc-tests, the reason is the ibc supervisor consist watching the two chains, but we do not fully implement the CKB relayer.

Please lookup from the error backtrace, it only affects the monitor fetching events operations.

Here is another example failed CI, if the error happend within the test case instead of the monitor, it will exit with a failure status. You need to find the first error output, which is raised from the test thread, not the monitor's error output.

https://github.com/synapseweb3/forcerelay/actions/runs/6182356419/job/16781928376

[ashuralyk]

Not ture, of course these CI are passed, the error messages are raised from monitor thread, becaused we haven't correctly implement the ibc4ckb interfaces.

I also found errors from monitor in Axon endpoint, and the monitor is essential for completing the watch of on-chain events and forward them to Hermes runtime to push the procedure, if it occurs errors, I think the procedure would be stopped.

Here is another example failed CI, if the error happend within the test case instead of the monitor, it will exit with a failure status. You need to find the first error output, which is raised from the test thread, not the monitor's error output.

this problem that I guess is caused by the usage of GLOBAL variables which store the association of IBC connection, channel, and packet with their Axon transactions' hash, I'm not sure whether running two parallel test cases in one instance would access these global variables at same time, which brings CACHE problem.

[jjyr]

the monitor is essential for completing the watch of on-chain events and forward them

I see, I will look into this issue. We could check the monitor thread status and raise an error from the test thread if the monitor is crashed.

I'm not sure whether running two parallel test cases in one instance would access these global variables at same time, which brings CACHE problem.

This is fixed in 412743c by run tests in single thread.

---

The monitor crash issue is already introduced, so IMO we should fix it in another PR.

Do you think we can merge this PR?

[ashuralyk]

the monitor is essential for completing the watch of on-chain events and forward them

I see, I will look into this issue. We could check the monitor thread status and raise an error from the test thread if the monitor is crashed.

I'm not sure whether running two parallel test cases in one instance would access these global variables at same time, which brings CACHE problem.

This is fixed in 412743c by run tests in single thread.

---

The monitor crash issue is already introduced, so IMO we should fix it in another PR.

Do you think we can merge this PR?

it's ok to me for the merge

[Flouse]

Is it possible to use timeout as the arg now?

[ashuralyk]

not yet for Axon, it's already under my consideration