smart wallet may drop offer notification (e.g. bids) on upgrade

[dckc]

Describe the bug

While investigating #8245, we found outstanding offers waiting for payouts. If Zoe is upgraded, the promise for the payouts will reject. The smartWallet code keeps its reference to the relevant seat, so the user can exit the offer. But it's not clear that they'll be notified promptly if the contract pays out.

Similarly, if the walletFactory is upgraded, the code processing the offer will not resume automatically.

To Reproduce

The bug is hypothesized; it has not yet been observed

1. Make a bid
2. Upgrade zoe
3. win auction
4. no change in wallet vstorage state

Expected behavior

Notifications of winning bids should still work after upgrading zoe.

Long-standing offers such as liquidation bids should survive upgrade of zoe.

Platform Environment

• what version of the Agoric-SDK are you using? (run git describe --tags --always)

mainnet1B

• what OS are you using? what version of Node.js?
• is there anything special/unusual about your platform?

follower node

Additional context

The promise @warner and I looked at in particular is:

subscriber	decider	kpid
v43-walletFactory	v9-zoe	kp356888

The suspect code is:

https://github.com/Agoric/agoric-sdk/blob/mainnet1B/packages/smart-wallet/src/offers.js#L142-L152

https://github.com/Agoric/agoric-sdk/blob/mainnet1B/packages/zoe/src/zoeService/zoeSeat.js#L318-L325

[dckc]

false alarm: the seat is kept, giving the user the ability to exit. They might not be notified promptly of winning an auction after zoe is upgraded, though.

https://github.com/Agoric/agoric-sdk/blob/mainnet1B/packages/smart-wallet/src/smartWallet.js#L503

[dckc]

@erights @Chris-Hibbert how should a zoe client handle a broken promise from E(seat).getPayouts()? Retrying is an option, but it seems to invite infinite loops.

[erights]

See how @gibson042 handles such retries in notifier/subscriber to avoid infinite loops. @gibson042 what's the best thing to look at first?

Of all the outstanding remote promises, the promises for payouts is the most important severing to recover from. Fortunately, you can just ask the seat again for the payouts, given that we can adapt @gibson042 's retry techniques to this case.

[gibson042]

reconnectAsNeeded uses isUpgradeDisconnection to detect situations where recovery from a broken promise may be possible by calling out to a provided getter function that is itself capable of returning similarly broken promises, and tolerates an arbitrarily long sequence of those as long as the incarnationNumber of each is strictly increasing.

[erights]

Yes, that's exactly what I had in mind. Thanks!

[dckc]

ah... const { incarnationNumber: version } = err;

So we take the other end's word for it regarding incarnationNumber.

[Chris-Hibbert]

Fixed by #8445.