-
Notifications
You must be signed in to change notification settings - Fork 215
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
migrate/improve auction functionality tests in z:acceptance
#10229
base: master
Are you sure you want to change the base?
Conversation
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.
I'll fully review when it's out of draft
b29d36e
to
50a0e17
Compare
Deploying agoric-sdk with Cloudflare Pages
|
f1dad49
to
a89e8e2
Compare
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.
I'll fully review when it's out of draft
a89e8e2
to
c32bcb5
Compare
…st time related complexities fix: apply change requests from PR review, resolve rebase conflicts, style fixes * change `performAction.js` name to `submitBid.js` * remove `Math.round` from `scale6` * update indexing of bids and other constants in `config` object to improve readability (`auction.test.js`) * move helper functions in `auction.test.js` to `test-lib/auction-lib.js` * move `lib/vaults.mts` to `test-lib/vaults.mts` and remove empty `lib` directory * let it be known `sync-tools.js` is a stand-in code for #10171 Refs: Agoric/BytePitchPartnerEng#8 fix: style fixes fix(acceptance-auction): lint fixes
b714d15
to
20ca789
Compare
…llision Refs: Agoric/BytePitchPartnerEng#31 fix(auction-acceptance): formatting fixes fix(auction-acceptance): formatting fixes
20ca789
to
bf05414
Compare
const [gov1Results, longLivingBidResults, user1Results, gov3Results, brands] = | ||
await Promise.all([ | ||
agoric | ||
.follow( |
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.
I lament that we still have to go out through the CLI to get this functionality that is in JS:
agoric-sdk/packages/agoric-cli/src/follow.js
Line 104 in 33309e0
case 'text': { |
Agoric/agoric-3-proposals#98 is related.
Filed #10369
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.
Definitely agree
closes: https://github.com/Agoric/BytePitchPartnerEng/issues/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.