Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(ARRR): dockerize zombie/pirate tests #2374

Open
wants to merge 22 commits into
base: dev
Choose a base branch
from
Open

Conversation

borngraced
Copy link
Member

@borngraced borngraced commented Feb 26, 2025

@borngraced borngraced self-assigned this Feb 26, 2025
@borngraced borngraced changed the title feat(ARRR): dockerize ZOMBIE tests feat(ARRR): dockerize zombie/pirate tests Feb 26, 2025
@shamardy
Copy link
Collaborator

shamardy commented Mar 3, 2025

@borngraced what is left to make this ready for review. @onur-ozkan @dimxy please ignore reviewing this until it's ready.

@borngraced
Copy link
Member Author

@borngraced what is left to make this ready for review. @onur-ozkan @dimxy please ignore reviewing this until it's ready.

Some minor adjustments to the zombie docker image still ongoing

@borngraced borngraced changed the base branch from dev to main March 4, 2025 22:06
@borngraced borngraced changed the base branch from main to dev March 4, 2025 22:07
"mm2":1,
"avg_blocktime": 60,
"avg_blocktime": 20,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is it set to 20 sec?
(I think it should be 60 for ZOMBIE as well)

Copy link
Member Author

@borngraced borngraced Mar 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted fast block production via docker image and I think it might have side effect with this which is why I updated it to the same average blocktime from the docker image https://github.com/KomodoPlatform/ZOMBIE_test_docker/blob/6a06dcf1cf08c52f95a18466b5adf33ad387396e/start_blockchain.py#L30(should be 10 tho.)

I can revert if you think the changes in the script above doesn't really matter.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see you changed ac_blocktime to 10.
avg_blocktime is used to estimate number of blocks from a duration, so I guess it's better to have it equal to ac_blocktime.


#[tokio::test(flavor = "multi_thread")]
async fn zombie_coin_send_and_refund_maker_payment() {
let _lock = TEST_MUTEX.lock().await;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should set this lock on the API level (not in tests only)
(to prevent this issue with parallel calls, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no sure how we can approach this btw.. since we need to wait from start to finish of a pirate swap.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we just should prevent a note to be selected the second time from the received_notes table.
It should not be selected after we update its spent status with the store_sent_tx fn.
So I guess, we need to set a lock before where we add notes and release it after the store_sent_tx fn called. The places in code where we add notes are: init_withdraw, z_send_dex_fee, z_send_htlc

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made a sample code with Z_NOTE_LOCK in the send_outputs fn (it's not ready for prod, just to prove the idea of a lock to prevent access to the available notes)

I also had to add a simple wait_for_z_balance fn, otherwise I had insufficient balance error. So probably the spendable_notes_required_for_tx fn does work properly when different ZCoin {} created in concurrent zombie tests or its confirmation logic is not sufficient: I noticed that transactions may stay for few blocks in mempool so I wait for 5 blocks in wait_for_z_balance.

Comment on lines 1123 to 1084
/// Initialize `ZCoin` with a forced `z_spending_key`.
#[allow(clippy::too_many_arguments)]
pub async fn z_coin_from_conf_and_params_with_docker(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be feature gated with run-docker-tests

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Comment on lines 30 to 31
#[cfg(not(target_arch = "wasm32"))]
use zcash_client_sqlite::error::SqliteClientError;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can move this into cfg_native block.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Comment on lines 89 to 90
// SAFETY: htlc_output is sending to a t_addr.
let to = htlc_output.script_pubkey.address().unwrap();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// SAFETY: htlc_output is sending to a t_addr.
let to = htlc_output.script_pubkey.address().unwrap();
let to = htlc_output.script_pubkey.address().expect("htlc_output is sending to a t_addr");

Comment on lines +121 to +122
pub const ZOMBIE_ASSET_DOCKER_IMAGE: &str = "docker.io/borngraced/zombietestrunner";
pub const ZOMBIE_ASSET_DOCKER_IMAGE_WITH_TAG: &str = "docker.io/borngraced/zombietestrunner:multiarch";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please upload those images to komodoofficial org? We should not rely on personal accounts (I know we already do for certain and we should migrate from them).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created a tracking issue for this: #2381

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the docker image needs to be reviewed first https://github.com/KomodoPlatform/ZOMBIE_test_docker

Comment on lines 173 to 174
// TODO: fix test
#[ignore]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's worth to put some context about the failure here, so we don't need to run the test in order to remember what was going wrong.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'm absolutely going to attend to test in this PR

@@ -1866,7 +1934,7 @@ impl InitWithdrawCoin for ZCoin {
memo,
};

let (tx, data, _sync_guard) = self.gen_tx(vec![], vec![z_output]).await?;
let (tx, _, data, _sync_guard) = self.gen_tx(vec![], vec![z_output]).await?;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is there no store_sent_tx() call for withdraw?

this PR is slowly diverting from it's main purpose hance, I have remove
additional fixes that shouldn't have been done here...removed fixes will
be reimplemented `fix-zombie-tests` PR
@borngraced
Copy link
Member Author

this PR(#2374) is slowly diverting from it's main purpose. Hence, I have removed additional fixes that shouldn't have been done here...removed fixes will
be re-implemented in `improve shielded transactions change notes handling in swaps PR.

@dimxy
Copy link
Collaborator

dimxy commented Mar 11, 2025

Do I understand it right that we are going to solve the problems with concurrent zombie tests failure?
If so I am okay with this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants