fix: Make the auction schedule robust when adding collateral types

[Chris-Hibbert]

closes: #8296

This fixes two problems.

• If the auction tried to start before a price had been captured from the oracle, it would crash the schedule.
• If a schedule existed, but it's nextStart was in the past, resetting the parameters didn't fix it. This checks to see if the existing schedule's start time has passed, and if so, restarts the schedule.

#8307 covers the additional issue of ensuring that all repeating timers in the auction should survive exceptions.

Description

If a new collateral type is added to the auctioneer before its price is available from an oracle, it breaks the schedule of all auctions in a way that is irretrievable.

Security Considerations

Auction shouldn't be this delicate.

Scaling Considerations

None.

Documentation Considerations

None.

Testing Considerations

Adds a test.

Upgrade Considerations

Has to wait for the ability to upgrade governed contracts.

[turadg]

from throw to warn… is it not an error to start the auction without a price feed?

agoric-sdk/packages/inter-protocol/src/vaultFactory/vaultManager.js

Lines 749 to 751 in fb2e7f5

	console.error(
	`⚠️ Excess collateral remaining sent to reserve. Expected ${q(
	plan.collatRemaining,

maybe not. I suppose we have decided it is part of the spec that the auction skips if there's no feed.

[Chris-Hibbert]

It's an error, but it should only affect the auction for that collateral. Throwing is an over-reaction.

[turadg]

Certainly throwing is an over-reaction. My question was about how to log.

It's an error

Then should it be console.error? Consider also ⚠️ in the message to draw attention to it in log output. I think "🚨" would be too severe as this is a known possible state.

[Chris-Hibbert]

I'm fine with error, though I haven't seen any evidence that it increases visibility.

I had intended to add a glyph, but forgot. Thanks for the reminder.

[turadg]

I think with the new await that the await null is redundant. But I'd propose instead only awaiting the timestamp if necessary.

Suggested change

	now = await E(timer).getCurrentTimestamp();
	if (
	!nextSchedule ||
	TimeMath.compareAbs(nextSchedule.startTime, now) < 0
	) {
	if (
	!nextSchedule ||
	TimeMath.compareAbs(nextSchedule.startTime, await E(timer).getCurrentTimestamp()) < 0
	) {

or perhaps more readably,

Suggested change

	now = await E(timer).getCurrentTimestamp();
	if (
	!nextSchedule ||
	TimeMath.compareAbs(nextSchedule.startTime, now) < 0
	) {
	const validSchedule = nextSchedule && TimeMath.compareAbs(nextSchedule.startTime, await E(timer).getCurrentTimestamp()) < 0;
	if (!validSchedule) {

[Chris-Hibbert]

This doesn't save now, so I end up making the call to getCurrentTimestamp inside a conditional.

        let repairableSchedule;
        if (!nextSchedule) {
          repairableSchedule = true;
        } else {
          now = await E(timer).getCurrentTimestamp();
          repairableSchedule =
            TimeMath.compareAbs(nextSchedule.startTime, now) < 0;
        }

        if (repairableSchedule) {

The TimeMath comparison will only be called if we did need to update now, so it's relatively clean. I tried to use a ternary, but it wasn't pretty (since the else has to be two statements--it's possible with a comma expression, but not great.)

[turadg]

Ah, I didn't realize now needs to be saved.

[turadg]

we need a regression test. so please change this test to ensure that a missing price feed does not throw.

[Chris-Hibbert]

Good idea. I'll add a test for that case. I think this test also needs to be part of the PR, just to show the reproduction scenario in case anyone needs to work through that.

[turadg]

LG, contingent upon removing the skipped test. (Thanks for including it to facilitate review.)

[turadg]

ACK