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

Market orders deprecation date remove #2536

Merged
merged 18 commits into from
Mar 29, 2024

Conversation

sunce86
Copy link
Contributor

@sunce86 sunce86 commented Mar 19, 2024

Description

Removes market_orders_deprecation_date as required in #2462. (no need to remove rank_by_surplus_date just yet)

Once removed, tests started failing, so we need to convert all tests for market orders to work with limit orders or to remove them if they don't make sense anymore.

How to test

Existing tests.

@sunce86 sunce86 changed the title DRAFT: Market orders deprecation date remove Market orders deprecation date remove Mar 25, 2024
@sunce86 sunce86 marked this pull request as ready for review March 25, 2024 16:52
@sunce86 sunce86 requested a review from a team as a code owner March 25, 2024 16:52
@sunce86
Copy link
Contributor Author

sunce86 commented Mar 25, 2024

The PR is ready to be reviewed now.

Copy link
Contributor

@MartinquaXD MartinquaXD left a comment

Choose a reason for hiding this comment

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

Looks good overall just surprised by 2 test changes.

);

let services = Services::new(onchain.contracts()).await;
let solver_endpoint = colocation::start_naive_solver().await;
Copy link
Contributor

Choose a reason for hiding this comment

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

Why does this test have to be removed. I think it's one of few (maybe the only one?) that tests that the naive solver is actually able to settle batches.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Naive solver does not support limit orders. When switched to using baseline (which does not do batch) I ended up with a classic limit order e2e test which is already covered with other tests.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ahh, right. Forgot that naive doesn't support computing the fee. 👌

Copy link
Contributor

Choose a reason for hiding this comment

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

How hard would it be to teach the naive solver to compute fees? On a high level it should be less hard than what the baseline solver does since it only ever uses one kind of pool? I think it would be good to have some basic CoW test coverage.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So I think we agreed on slack to ditch Naive solver (this PR is happy for it).

Copy link
Contributor

Choose a reason for hiding this comment

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

Can we capture a task to bring this test back if we resurrect naive solver (I do think for e2e tests specifically it would be good to have a solver that's capable of matching basic CoWs)

crates/e2e/tests/e2e/smart_contract_orders.rs Show resolved Hide resolved
@m-lord-renkse
Copy link
Contributor

LGMT

Copy link
Contributor

@fleupold fleupold left a comment

Choose a reason for hiding this comment

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

Looks good, but I think we are removing a few e2e tests that are still adding value.

@@ -125,6 +123,6 @@ async fn eth_integration(web3: Web3) {
);
assert_eq!(
trader_b_eth_balance_after - trader_b_eth_balance_before,
49_776_284_258_574_379_601_u128.into()
Copy link
Contributor

Choose a reason for hiding this comment

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

These tests strike me as useful as a chocolate teapot, basically whenever they fail we just rerun the assertion and update the value (so it's not really testing anything useful).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think the proper assert here would be
trader_b_eth_balance_after >= 49 eth

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed as suggested by myself 😄

@@ -148,122 +131,6 @@ async fn eth_flow_tx_zero_fee(web3: Web3) {
.await;
}

async fn eth_flow_tx(web3: Web3) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this test removed, it still seems legit?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I spent some time figuring out why some tests were removed. Would appreciate more context on this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not actually removed, it's just code diff shows it in a weird way.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

local_node_eth_flow_insufficient_fee and local_node_eth_flow_zero_fee are removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

and local_node_eth_flow_tx is changed to be actually local_node_eth_flow_zero_fee :)

@@ -297,132 +291,6 @@ async fn two_limit_orders_test(web3: Web3) {
assert!(balance_after_b.checked_sub(balance_before_b).unwrap() >= to_wei(2));
}

async fn mixed_limit_and_market_orders_test(web3: Web3) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Ditto, this test case still seems useful

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If we remove market order as we do not support it anymore, we are left with 1 limit order (which is actually in-market) and we already have this test covered with local_node_single_limit_order

);

let services = Services::new(onchain.contracts()).await;
let solver_endpoint = colocation::start_naive_solver().await;
Copy link
Contributor

Choose a reason for hiding this comment

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

How hard would it be to teach the naive solver to compute fees? On a high level it should be less hard than what the baseline solver does since it only ever uses one kind of pool? I think it would be good to have some basic CoW test coverage.

crates/shared/src/order_validation.rs Show resolved Hide resolved
@sunce86 sunce86 requested review from fleupold and squadgazzz March 27, 2024 16:48
);

let services = Services::new(onchain.contracts()).await;
let solver_endpoint = colocation::start_naive_solver().await;
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we capture a task to bring this test back if we resurrect naive solver (I do think for e2e tests specifically it would be good to have a solver that's capable of matching basic CoWs)

@@ -13,7 +13,6 @@ pub enum OnchainOrderPlacementError {
DisabledOrderClass,
ValidToTooFarInFuture,
InvalidOrderData,
InsufficientFee,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hm, wonder If I am allowed to delete the variant (for backward compatibility with older orders that might have this error)

Copy link
Contributor

Choose a reason for hiding this comment

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

You are right, this would probably lead to issues if the order is read from disk

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I reverted the bare minimum of InsufficientFee in database so that, when we fetch old orders that have this error, nothing breaks.

@sunce86
Copy link
Contributor Author

sunce86 commented Mar 29, 2024

Captured the remaining task: #2578

@sunce86 sunce86 merged commit ad8cd1b into main Mar 29, 2024
9 checks passed
@sunce86 sunce86 deleted the market_orders_deprecation_date-remove branch March 29, 2024 12:21
@github-actions github-actions bot locked and limited conversation to collaborators Mar 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants