-
Notifications
You must be signed in to change notification settings - Fork 313
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
route_and_fill proptests #4509
route_and_fill proptests #4509
Conversation
# It is recommended to check this file in to source control so that | ||
# everyone who runs the test benefits from these saved cases. | ||
cc 0c03c0969eb36a1545d8a596759b19b4b297adb875bbeea04af714f1c7b132a4 # shrinks to sell_penumbra_for_gn_position = Position { state: Opened, reserves: Reserves { r1: 0, r2: 0 }, phi: TradingFunction { component: BareTradingFunction { fee: 0, p: 0, q: 0 }, pair: TradingPair { asset_1: passet1984fctenw8m2fpl8a9wzguzp7j34d7vravryuhft808nyt9fdggqxmanqm, asset_2: passet1nupu8yg2kua09ec8qxfsl60xhafp7mmpsjv9pgp50t20hm6pkygscjcqn2 } }, nonce: "9acd0464c98e0f122223613f4721c9a5feaf720e54ef2dec32c02a350e6fcb81" }, sell_gm_for_gn_position = Position { state: Opened, reserves: Reserves { r1: 0, r2: 0 }, phi: TradingFunction { component: BareTradingFunction { fee: 0, p: 0, q: 0 }, pair: TradingPair { asset_1: passet1r4kcf2m4r92jqmdks5c9yt7v2tgnht4aj3fml4qln56x72nm8qrsm9d598, asset_2: passet1nupu8yg2kua09ec8qxfsl60xhafp7mmpsjv9pgp50t20hm6pkygscjcqn2 } }, nonce: "cb352b88f8ee4076b4f6b8e59a7a2159485870743e1adbdc588cb43e9eab7a3a" }, sell_gn_for_penumbra_position = Position { state: Opened, reserves: Reserves { r1: 0, r2: 0 }, phi: TradingFunction { component: BareTradingFunction { fee: 0, p: 0, q: 0 }, pair: TradingPair { asset_1: passet1984fctenw8m2fpl8a9wzguzp7j34d7vravryuhft808nyt9fdggqxmanqm, asset_2: passet1nupu8yg2kua09ec8qxfsl60xhafp7mmpsjv9pgp50t20hm6pkygscjcqn2 } }, nonce: "81f54dd987a6a7daf96d986ef005b390dd24ff1fda6249dc5de112509a321782" }, input_amount = 0 | ||
cc 3854e480dc5fe1428eecc71207e8ffbf2859539ef407c149b163ed19703e212b # shrinks to input_amount = 1625583888576709026, num_paths_1 = 15, num_paths_2 = 5, num_paths_3 = 6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately I think the strategy created invalid positions, where p=q=0 and empty reserves too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
grr, I think I committed the wrong failing proptest, the current strategy shouldn't produce those values... 1s
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@erwanor i just pushed up a new proptest file, it had some junk in it from previous development runs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(new one fails on _pre_4283
branch, passes on this one)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sick thanks, taking a look!
b010ec2
to
426f4af
Compare
@erwanor I think this PR doesn't fulfill any current testing requirements. Are there any tests you can think of that would be more appropriate, or should we just close this out? |
Yeah I think we can close this and revisit in a few weeks. |
Describe your changes
This adds a proptest function for exercising
route_and_fill
. In particular, it checks for the issue fixed in #4283 . After backporting the proptest to the commit previous to #4283, I was able to reproduce the described issue (check out the4299_route_and_fill_proptest_pre_4283
branch andcargo test --package penumbra-dex --lib -- component::router::tests::test_paths_dont_lose_money
to reproduce) and create a failing proptest definition. I then brought this failing proptest definition over to the main branch, ran the proptests, and validated that the test now passes.It makes sense that the issue fixed in #4283 could have caused the behavior described in #4299.
This proptest introduces two checks: that value is never lost during a trace (this may happen due to rounding, and this test may actually be undesirable) and that the same position is never executed against twice for a given swap execution (is this desirable? It seems possible for there to be cases where a position could be executed against in multiple traces).
Issue ticket number and link
Closes #4299
Checklist before requesting a review
If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: