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

Refactor stop-loss create just 1 discrete order #89

Conversation

yvesfracari
Copy link
Contributor

Description

  • Avoid multiple discrete order creations for one stop-loss order creation.

Changes

  • Replace the validityBucketTime parameter of stop loss data with constant validTo.

How to test

  1. Run the modified local test.
  2. Try to create multiple discrete orders from the same stop-loss order using the deployed contract on sepolia: 0xe6CDbC068654C506424F7747357F51d0e7caB00e

@ribeirojose ribeirojose force-pushed the pedro/cow-324-create-new-stop-loss-handler-with-constant-validto branch from 652e0a2 to 0c673e0 Compare July 24, 2024 15:32
src/types/StopLoss.sol Outdated Show resolved Hide resolved
@mfw78 mfw78 requested review from mfw78 and fedgiac July 30, 2024 12:20
Copy link
Contributor

@fedgiac fedgiac left a comment

Choose a reason for hiding this comment

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

The changes look good, but why was it previously implemented in bucket?
My only guess is that maybe long-lived orders aren't accepted by the API. In case, has this changed?

test/ComposableCoW.stoploss.t.sol Outdated Show resolved Hide resolved
maxTimeSinceLastOracleUpdate: 15 minutes
});

vm.expectRevert(
Copy link
Contributor

Choose a reason for hiding this comment

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

It would be better if there was also a test that shows an order is valid if warping to validTo, all other tests use type(uint256).max for the valid to so the positive boundary condition isn't tested on a different number.

@mfw78
Copy link
Contributor

mfw78 commented Aug 5, 2024

The changes look good, but why was it previously implemented in bucket? My only guess is that maybe long-lived orders aren't accepted by the API. In case, has this changed?

Because I was foolish when I implemented it 🙈 This was the last conditional order type that I added "last minute". Never do things "last minute" it seems 🤦‍♂️

Copy link
Contributor

@mfw78 mfw78 left a comment

Choose a reason for hiding this comment

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

Concur with the review comments from @fedgiac

@yvesfracari yvesfracari requested review from mfw78 and fedgiac August 5, 2024 13:58
@yvesfracari
Copy link
Contributor Author

@mfw78 once this is merged, let us know if we should deploy this contract on all chains or you will do it.

fedgiac
fedgiac previously approved these changes Aug 5, 2024
test/ComposableCoW.stoploss.t.sol Outdated Show resolved Hide resolved
Co-authored-by: Federico Giacon <[email protected]>
@yvesfracari yvesfracari requested a review from fedgiac August 5, 2024 19:14
@mfw78 mfw78 merged commit 9666d9d into cowprotocol:main Aug 6, 2024
2 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Aug 6, 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.

4 participants