migrate/improve auction functionality tests in z:acceptance
#10229
+1,300
−22
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
closes: Agoric/BytePitchPartnerEng#8
closes: #10111
Description
Currently acceptance tests do not cover auction functionality. When we look at the proposals in https://github.com/Agoric/agoric-3-proposals, there are no tests that check for depositors or bidders payouts from a given auction. There is code for changing auction params here and there, including
z:acceptance
.In this PR, we test an auction from start to end. Here's the test case implemented;
USE
phase ofn:upgrade-next
, we place a bidTEST
phase ofz:acceptance
gov1
deposits 100 IST to ATOM auction bookuser1
places a bidgov2
places a bidWhy is this PR a draft?
This pr depends on tools in #10171, as soon that's approved I'll rebase this one on top of that one.
Security Considerations
None.
Scaling Considerations
Currently this test takes from 4-5 minutes to 12-13 minutes. It can take up to 20 minutes. This is because how the auction params are set. Why not just change the auction params? See
Testing Considerations
.Documentation Considerations
None.
Testing Considerations
Testing
auctions
in a3p have a huge disadvantage since we don't have any tools for controlling how the time advances when running an actual node. I believe Agoric/agoric-3-proposals#179 should be a priority as it will unlock very comprehensive test coverage in a3p testing.Since time is a variable that we cannot control but it also plays a huge role when running our auction tests, we need to wait for it. Another complication is coming from how a3p images are built. Imagine this scenario;
t - 3
nextStartTime
of the auction schedule wast - 1
t
t
the waker set for the roundt - 1
is triggered before ourrun-test.sh
is runt - 1
when it is actually att
t - 1
to start att + 1
t + 1
is now theactiveStartTime
but there's a+1
delay that we have to wait foractiveStartTime
is already captured when thet - 1
waker run during the fast forward when chain restartednewStartTime
newStartTime
t
) PLUS a whole auction roundThis scenario is common when
yarn test -m acceptance
uses caching as the latest cached layer will have it's state at when it was built. So if you built your latest cached layer an hour ago and auction start frequency is 10 minutes, you will face this issue.If the latest cached layer is built less than 15 mins ago (10 mins round time and 5 mins
maxLate
, auctioneer is okay if round starts late less than 5 mins), it is very unlikely that you will face this issue("unlikely" because my math there might be wrong.) So I assume we will not face this issue when running in CI as I think all build layers are built from scratch in CI.Why not update auction params?
Changed params take effect AFTER the next scheduled round. We are only interested in the next scheduled round since it is the soonest we can start depositing and bidding. One way to make the changed params effective for the next scheduled round in our
test-acceptance
build might be to change them in an earlier proposalUSE
state which means we have to depend on the global state to carry out our tests which is something I'm not a fan of.Who places the long living bid?
Again, in order not to depend on global state we create a new user called
long-living-bidder
. Because other tests might mess with the bidder's wallet history and make querying payouts more complex.Upgrade Considerations
None.