You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #690, branch musitdev/e2e_mvt_eth_happy_path, when running Movement initiator-side tests in , there is an inconsistent pass vs failure behavior where there are sometimes two successful tests followed by constantly repeating failures, or sometimes one to all three of the Movement-side initiated transfers fail. It seems to be related to something inconsistent either in the tests or in the node.
Example terminal output when successfully running: DOT_MOVEMENT_PATH="$(pwd)/.movement" cargo test --test client_mvt_tests movement_client_refund_transfer -- --nocapture --test-threads=1 against a local node already running with `:
These are not the bridge logs, they are only the testing terminal output.
I was expecting a pattern I had previously seen where all tests pass twice and then repeatedly fail. However, now there's a sort of cyclical-seeming but I think maybe just irregular pattern. I performed the tests a few times. (See timestamps for pattern.)
Repeated WARN statements are removed for brevity.
Example of passing tests: This typically happens when the node first starts, all tests will pass. Sometimes there has been a pattern where all 5 tests pass twice then fail repeatedly, but I haven't been able to reproduce it.
Example of test_movement_client_initiate_transfer and test_movement_client_initiator_complete_transfer failing
Some Movement-initiator side tests fail when running DOT_MOVEMENT_PATH="$(pwd)/.movement" cargo test --test client_mvt_tests -- --nocapture --test-threads=1
running 5 tests
test test_movement_client_abort_transfer ... 2024-11-14T19:10:48.497387Z INFO bridge_service::chains::movement::utils: Starting send_aptos_transaction
2024-11-14T19:11:12.537075Z INFO bridge_service::chains::movement::utils: Starting send_aptos_transaction
ok
test test_movement_client_counterparty_complete_transfer ... 2024-11-14T19:11:23.138897Z INFO bridge_service::chains::movement::utils: Starting send_aptos_transaction
2024-11-14T19:11:27.181382Z INFO client_mvt_tests: Bridge transfer details: BridgeTransferDetailsCounterparty { bridge_transfer_id: BridgeTransferId([123, 23, 179, 145, 243, 184, 163, 56, 53, 25, 141, 130, 56, 57, 222, 203, 191, 103, 215, 205, 75, 66, 74, 19, 82, 169, 83, 219, 49, 202, 176, 128]), initiator_address: BridgeAddress([51, 50, 66, 101, 51, 52, 51, 66, 57, 52, 102, 56, 54, 48, 49, 50, 52, 100, 67, 52, 102, 69, 101, 50, 55, 56, 70, 68, 67, 66, 68, 51, 56, 67, 49, 48, 50, 68, 56, 56]), recipient_address: BridgeAddress(MovementAddress(3078303030303030303030303030303030303030303030303030303066616365)), hash_lock: HashLock([16, 190, 189, 199, 22, 62, 83, 217, 97, 214, 87, 114, 62, 139, 179, 115, 176, 115, 151, 54, 139, 7, 233, 198, 233, 114, 109, 141, 87, 5, 4, 142]), time_lock: TimeLock(1731611491), amount: Amount(1), state: 1 }
2024-11-14T19:11:27.181542Z INFO bridge_service::chains::movement::utils: Starting send_aptos_transaction
ok
test test_movement_client_initiate_transfer ... 2024-11-14T19:11:35.264342Z INFO bridge_service::chains::movement::utils: Starting send_aptos_transaction
2024-11-14T19:11:39.301980Z INFO client_mvt_tests: Initiate result: ()
2024-11-14T19:11:39.302028Z INFO client_mvt_tests: Wait for the Movement Initiated event.
2024-11-14T19:11:39.302698Z WARN bridge_service::chains::movement::event_monitoring: Check Mvt monitoring loop health channel error: receiving on a closed channel
thread 'test_movement_client_initiate_transfer' panicked at protocol-units/bridge/integration-tests/tests/client_mvt_tests.rs:133:10:
Timeout while waiting for the Movement Initiated event: Elapsed(())
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
FAILED
test test_movement_client_initiator_complete_transfer ... 2024-11-14T19:12:13.855641Z INFO bridge_service::chains::movement::utils: Starting send_aptos_transaction
2024-11-14T19:12:17.892457Z INFO client_mvt_tests: Initiate result: ()
2024-11-14T19:12:17.892520Z INFO client_mvt_tests: Wait for the Movement Initiated event.
2024-11-14T19:12:47.482428Z WARN bridge_service::chains::movement::event_monitoring: Check Mvt monitoring loop health channel error: receiving on a closed channel
thread 'test_movement_client_initiator_complete_transfer' panicked at protocol-units/bridge/integration-tests/tests/client_mvt_tests.rs:276:10:
Timeout while waiting for the Movement Initiated event: Elapsed(())
FAILED
test test_movement_client_refund_transfer ... 2024-11-14T19:12:49.926430Z INFO bridge_service::chains::movement::utils: Starting send_aptos_transaction
2024-11-14T19:12:53.955507Z INFO client_mvt_tests: Initiate result: ()
2024-11-14T19:12:53.955530Z INFO client_mvt_tests: Wait for the Movement Initiated event.
2024-11-14T19:12:53.955842Z WARN bridge_service::chains::movement::event_monitoring: Check Mvt monitoring loop health channel error: receiving on a closed channel
Initiate event data: Object {"amount": String("100"), "bridge_transfer_id": String("0xc4b9ce501772b71edb3d36c3c7807cfd59fa4c512a42fb18021524094c09f39c"), "hash_lock": String("0xf375d615c403d648a54f6c2ffdf04acbd78edfe7b29b8929026c654430037180"), "initiator": String("0xf90391c81027f03cdea491ed8b36ffaced26b6df208a9b569e5baf2590eb9b16"), "recipient": String("0x33324265333433423934663836303132346443346645653237384644434244333843313032443838"), "time_lock": String("11")} sequence_number:17
Initiate event transfer_details: BridgeTransferDetails { bridge_transfer_id: BridgeTransferId([196, 185, 206, 80, 23, 114, 183, 30, 219, 61, 54, 195, 199, 128, 124, 253, 89, 250, 76, 81, 42, 66, 251, 24, 2, 21, 36, 9, 76, 9, 243, 156]), initiator_address: BridgeAddress(MovementAddress(f90391c81027f03cdea491ed8b36ffaced26b6df208a9b569e5baf2590eb9b16)), recipient_address: BridgeAddress([51, 50, 66, 101, 51, 52, 51, 66, 57, 52, 102, 56, 54, 48, 49, 50, 52, 100, 67, 52, 102, 69, 101, 50, 55, 56, 70, 68, 67, 66, 68, 51, 56, 67, 49, 48, 50, 68, 56, 56]), hash_lock: HashLock([243, 117, 214, 21, 196, 3, 214, 72, 165, 79, 108, 47, 253, 240, 74, 203, 215, 142, 223, 231, 178, 155, 137, 41, 2, 108, 101, 68, 48, 3, 113, 128]), time_lock: TimeLock(11), amount: Amount(100), state: 0 }
2024-11-14T19:12:53.959874Z INFO client_mvt_tests: Received bridge_transfer_id: BridgeTransferId([196, 185, 206, 80, 23, 114, 183, 30, 219, 61, 54, 195, 199, 128, 124, 253, 89, 250, 76, 81, 42, 66, 251, 24, 2, 21, 36, 9, 76, 9, 243, 156])
2024-11-14T19:12:54.462032Z WARN bridge_service::chains::movement::event_monitoring: Check Mvt monitoring loop health channel error: receiving on a closed channel
2024-11-14T19:12:54.967329Z WARN bridge_service::chains::movement::event_monitoring: Check Mvt monitoring loop health channel error: receiving on a closed channel
2024-11-14T19:13:08.712284Z WARN bridge_service::chains::movement::event_monitoring: Check Mvt monitoring loop health channel error: receiving on a closed channel
2024-11-14T19:13:08.961858Z INFO client_mvt_tests: Current timestamp: 1731611588
2024-11-14T19:13:08.962004Z INFO bridge_service::chains::movement::utils: Starting send_aptos_transaction
2024-11-14T19:13:12.281627Z WARN bridge_service::chains::movement::event_monitoring: Check Mvt monitoring loop health channel error: receiving on a closed channel
refund event data: Object {"bridge_transfer_id": String("0xc4b9ce501772b71edb3d36c3c7807cfd59fa4c512a42fb18021524094c09f39c")} sequence_number:6
2024-11-14T19:13:12.501902Z INFO client_mvt_tests: Transfer details after refund: BridgeTransferDetails { bridge_transfer_id: BridgeTransferId([196, 185, 206, 80, 23, 114, 183, 30, 219, 61, 54, 195, 199, 128, 124, 253, 89, 250, 76, 81, 42, 66, 251, 24, 2, 21, 36, 9, 76, 9, 243, 156]), initiator_address: BridgeAddress(MovementAddress(f90391c81027f03cdea491ed8b36ffaced26b6df208a9b569e5baf2590eb9b16)), recipient_address: BridgeAddress([51, 50, 66, 101, 51, 52, 51, 66, 57, 52, 102, 56, 54, 48, 49, 50, 52, 100, 67, 52, 102, 69, 101, 50, 55, 56, 70, 68, 67, 66, 68, 51, 56, 67, 49, 48, 50, 68, 56, 56]), hash_lock: HashLock([243, 117, 214, 21, 196, 3, 214, 72, 165, 79, 108, 47, 253, 240, 74, 203, 215, 142, 223, 231, 178, 155, 137, 41, 2, 108, 101, 68, 48, 3, 113, 128]), time_lock: TimeLock(1731611584), amount: Amount(100), state: 3 }
ok
failures:
failures:
test_movement_client_initiate_transfer
test_movement_client_initiator_complete_transfer
test result: FAILED. 3 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; finished in 146.03s
Repeatedly run DOT_MOVEMENT_PATH="$(pwd)/.movement" cargo test --test client_mvt_tests -- --nocapture --test-threads=1 against the musitdev/e2e_mvt_eth_happy_path branch
Expected behavior
All tests should always pass.
Additional context
Movement -> Eth E2E Test Errors #831 contains details about failures in E2E tests that appear to potentially be related. From what I can tell this may be related to the event monitoring somehow failing to pick up events. I'm not sure. Any insight is appreciated.
The text was updated successfully, but these errors were encountered:
Describe the bug
In #690, branch
musitdev/e2e_mvt_eth_happy_path
, when running Movement initiator-side tests in , there is an inconsistent pass vs failure behavior where there are sometimes two successful tests followed by constantly repeating failures, or sometimes one to all three of the Movement-side initiated transfers fail. It seems to be related to something inconsistent either in the tests or in the node.DOT_MOVEMENT_PATH="$(pwd)/.movement" cargo test --test client_mvt_tests movement_client_refund_transfer -- --nocapture --test-threads=1
against a local node already running with `:These are not the bridge logs, they are only the testing terminal output.
I was expecting a pattern I had previously seen where all tests pass twice and then repeatedly fail. However, now there's a sort of cyclical-seeming but I think maybe just irregular pattern. I performed the tests a few times. (See timestamps for pattern.)
Repeated WARN statements are removed for brevity.
Example of passing tests: This typically happens when the node first starts, all tests will pass. Sometimes there has been a pattern where all 5 tests pass twice then fail repeatedly, but I haven't been able to reproduce it.
Example of
test_movement_client_initiate_transfer
andtest_movement_client_initiator_complete_transfer
failingSome Movement-initiator side tests fail when running
DOT_MOVEMENT_PATH="$(pwd)/.movement" cargo test --test client_mvt_tests -- --nocapture --test-threads=1
Refund failing
Initiate and initiator_complete failing
Only 1 failure but it's complete instead of refund
Initiate and refund failing
Only Initiate failing
After that, all tests passed again.
To Reproduce
DOT_MOVEMENT_PATH="$(pwd)/.movement" cargo test --test client_mvt_tests -- --nocapture --test-threads=1
against themusitdev/e2e_mvt_eth_happy_path
branchExpected behavior
All tests should always pass.
Additional context
The text was updated successfully, but these errors were encountered: