-
Notifications
You must be signed in to change notification settings - Fork 207
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: delay addition of issuer to auctioneer until a good time #8398
Conversation
I added a test file.
I think those would cover all the interesting cases, though it may be that i'm not thinking of enough edge conditions, so just before an auction starts, or just before it completes might give results I don't expect. |
178cc76
to
6e90832
Compare
6e90832
to
2a8fc5d
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.
first pass
const addBrandThenResolve = ToFarFunction('addBrandThenResolve', async () => { | ||
await E(auctioneerCreator).addBrand(interchainIssuer, keyword); | ||
finishPromiseKit.resolve(true); | ||
return true; |
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 don't see this value read. I think this function is meant to be void.
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.
fixed
const finishPromiseKit = makePromiseKit(); | ||
const addBrandThenResolve = ToFarFunction('addBrandThenResolve', async () => { | ||
await E(auctioneerCreator).addBrand(interchainIssuer, keyword); | ||
finishPromiseKit.resolve(true); |
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 don't see this value read. I think it's meant to be:
finishPromiseKit.resolve(true); | |
finishPromiseKit.resolve(undefined); |
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.
correct
makeLiquidationTestContext, | ||
} from './liquidation.ts'; | ||
|
||
const test = anyTest as TestFn<LiquidationTestContext>; |
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.
grand
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 copied this from a nearby test. I don't even know what it means. Care to explain? What's it do, and why is it "grand"?
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.
grand that you're using TS syntax ;-)
It means: "define test
to be the value of anyTest
with the type TestFn
with its Context
type parameter set to LiquidationTestContext
". TestFn
ensures that any test
methods and descendants (like t
) are typed The default t.context
is unknown
so the parameter slot fills that in with the actual context being assigned in line 16.
Though I see on line 30 that you're adding proposal
to the context. To not get a type error, include it here.
const test = anyTest as TestFn<LiquidationTestContext>; | |
const test = anyTest as TestFn<LiquidationTestContext & { proposal: Awaited<ReturnType<typeof buildProposal>> }>; |
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.
Though seeing further down, I don't think the raw proposal should go into the context because it's really more of a template. See request below for providing a helper function instead.
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.
done, though the declarations are a little more involved than that.
await advanceTimeTo(afterEndTime); | ||
|
||
const schedulesAfter = await EV(auctioneerKit.creatorFacet).getSchedule(); | ||
// brand equality is broken |
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.
how and why?
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.
TimeMath.compareAbs() complains that the brands don't match. I dunno why, but I suspect it's a result of whatever forces us to use EV
here instead of E
. How should I phrase that?
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'm surprised object identity of brands isn't preserved here. I thought maybe you were getting the brands from 2 different places - one from the kernel and one from vstorage - but not so; both are coming from calls to the creatorFacet
by way of the kernel.
EV
used to preserve object identity in such circumstances, I believe.
@gibson042 @FUDCo was there a regression in #8373 ? Or is my mental model just off?
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.
Well, it's partially that your mental model is a bit off but there was a change that is part of the story here. You cannot directly compare object identity on the stuff you get back from EV
, though reason is not actually EV
itself but kmarshal
, which previously had internal state that we've now gotten rid of because it was fundamentally incompatible with importation into different compartments. To address this there are now a handful of matchXXX
functions in the same supports
module with EV
. To compare two object references (such as to brands) for equality, the one you want is matchRef
.
(Though to be clear, there are some important limitations of EV
that people seem to be oblivious to that they need to be more broadly educated about, but I don't think they're involved in this particular case.)
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.
You cannot directly compare object identity on the stuff you get back from
EV
noted. thanks for confirming.
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 updated the comment to clarify the reason it can't use TimeMath.compareAbs()
.
Does this somehow subsume the oracle constraint from #8347 ?
|
It does not. If we're worried about that, we should add a check somewhere that an oracle is available. |
My understanding of #8347 is that we are worried about that. Please do add a check that the oracle is available; for example, ask for (and await) a quote. p.s. later discussion concluded that yes, this PR does subsume the oracle constraint check. |
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.
Logic of proposal and test look correct to me.
Please do the requested refactorings before merge.
makeLiquidationTestContext, | ||
} from './liquidation.ts'; | ||
|
||
const test = anyTest as TestFn<LiquidationTestContext>; |
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.
grand that you're using TS syntax ;-)
It means: "define test
to be the value of anyTest
with the type TestFn
with its Context
type parameter set to LiquidationTestContext
". TestFn
ensures that any test
methods and descendants (like t
) are typed The default t.context
is unknown
so the parameter slot fills that in with the actual context being assigned in line 16.
Though I see on line 30 that you're adding proposal
to the context. To not get a type error, include it here.
const test = anyTest as TestFn<LiquidationTestContext>; | |
const test = anyTest as TestFn<LiquidationTestContext & { proposal: Awaited<ReturnType<typeof buildProposal>> }>; |
}); | ||
|
||
test.after.always(t => { | ||
// This will fail if a subset of tests are run. It detects that three |
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.
Why do we need this check? Is each test not independent?
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.
Each test now ends by verifying that readLatest(
${auctioneerPath}.book1)
finds something. What's actually happening is that the tests will sequentially add book1
, book2
, and book3
. In order to allow for parallelism, since they take so long, I didn't make them sequential, so I don't know what order they run in.
I could have each test check all three potentially-present nodes and verify that one has a matching name. I thought it more straightforward to verify in the .after
that 3 had been added. Please let me know if you think there's a more legible approach.
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.
Actually, now that I moved building the proposal into .before
, the total time was 38s. When I modified the tests to .serial
that grew to 40s, which is probably not significant.
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.
not significant. also probably a smaller difference in CI with fewer cores.
makeLiquidationTestContext, | ||
} from './liquidation.ts'; | ||
|
||
const test = anyTest as TestFn<LiquidationTestContext>; |
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.
Though seeing further down, I don't think the raw proposal should go into the context because it's really more of a template. See request below for providing a helper function instead.
2ea7c35
to
6d52bcb
Compare
closes: #8347
Description
When adding a new asset type, delay until the auction is quiescent, so as not to trigger #8296.
Security Considerations
Don't break the chain.
Scaling Considerations
Not an issue here.
Documentation Considerations
Not applicable.
Testing Considerations
I added bootstrapTests that wait until a propitious or hazardous time to add the collateral, and verify that addAssetsToVault waits for the auction to quiesce, and succeeds in adding a new collateral type.
Upgrade Considerations
This applies to adding asset types, not upgrading contracts.