-
Notifications
You must be signed in to change notification settings - Fork 208
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
backport walletFactory improvements on top of upgrade-11 branch #8311
Conversation
I don't understand why
https://github.com/Agoric/agoric-sdk/actions/runs/6101013890/job/16556480500?pr=8311#step:3:525 |
It's possibly an artifact of the cherry-pick that happened previously in this branch Edit: nope there is a dep change |
"@endo/captp": "^3.1.1", | ||
"@endo/init": "^0.5.56", | ||
"ava": "^5.2.0" | ||
"ava": "^5.2.0", | ||
"import-meta-resolve": "^2.2.1" |
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.
Here is the dependency change
const importSpec = spec => | ||
importMetaResolve(spec, import.meta.url).then(u => new URL(u).pathname); |
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 think it would be nice to avoid taking on an import-meta-resolve
dependency just for this.
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 not aware of an alternative. It's pretty normal for tests that use bundleSource
, no?
In master, I think the dependency was/is already there.
@@ -0,0 +1,2 @@ | |||
upgrade-walletFactory-permit.json |
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.
Instead of adding these as ignores, can we move them to the tmp directory after agoric run
produces the files?
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 suppose we could. But since bash lacks stuff like "find all references", it's sort of a pain to do. A few hours of trial-and-error. Does it seem worthwhile?
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 a blocker; something to revisit later. may fall out of other rearrangements.
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.
The upgrade tests looks like it's testing what it needs to.
The rest of the code has been reviewed to get into master. I skimmed it again and left some comments. I leave to you whether they raise anything that requires a change before landing.
@@ -0,0 +1,2 @@ | |||
upgrade-walletFactory-permit.json |
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 a blocker; something to revisit later. may fall out of other rearrangements.
. ./upgrade-test-scripts/env_setup.sh | ||
# Dockerfile in upgrade-test sets: | ||
# WORKDIR /usr/src/agoric-sdk/ | ||
# Overriding it during development has occasionally been useful. |
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.
thanks for explanation
# Pay 0.25IST join the game and get some places | ||
node ./wallet-all-ertp/gen-game-offer.mjs Shire Mordor >/tmp/,join.json | ||
agops perf satisfaction --from $GOV1ADDR --executeOffer /tmp/,join.json --keyring-backend=test |
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.
NTS: with new Platform PM take stock of our CLI tools
node ./wallet-all-ertp/gen-game-offer.mjs Shire Mordor >/tmp/,join.json | ||
agops perf satisfaction --from $GOV1ADDR --executeOffer /tmp/,join.json --keyring-backend=test | ||
cd $SDK |
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.
is this necessary?
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.
no.
it was when the next step was something to do with upgrading zoe.
I'm not sure why I left it in. But doesn't seem worth another ci spin.
@@ -23,3 +23,45 @@ mv $TMP_GENESIS_DIR/priv_validator_state.json $HOME/.agoric/data | |||
mv $TMP_GENESIS_DIR/* $HOME/.agoric/config/ | |||
rm -rf $EXPORT_DIR | |||
startAgd | |||
|
|||
testMinChildren() { |
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 see why you wanted to use @iomekam 's JS functions instead!
console.log('upgradeWalletFactory: config', config); | ||
const { walletFactoryRef } = config.options; | ||
|
||
// console.log('upgradeWalletFactory: awaiting instances etc.'); |
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.
We should try not to have commented-out code.
Please uncomment or remove. I suggest uncomment as its appropriate for proposals to be verbose.
}); | ||
// console.log('upgradeWalletFactory: awaiting walletReviver'); | ||
const walletReviver = await E(ppKit.creatorFacet).getWalletReviver(); | ||
const newPrivateArgs = harden({ |
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.
shouldn't these be the same privateArgs as the running instance?
you can get those from instancePrivateArgs
in bootstrap promise space.
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.
seems like I tried to do that... trying to remember why I went another way...
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 think it was about instancePrivateArgs
being only for diagnostic / testing purposes.
But maybe using it in production for upgrade purposes is appropriate?
I wonder about divergence from master, but I think I'll give it a try...
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.
hm...
2023-09-08T01:05:40.125Z SwingSet: vat: v1: upgradeWalletFactory: upgrading with privateArgs { storageNode: Object [Alleged: ChainStorageNode] {}, walletBridgeManager: Object [Alleged: BridgeScopedManager] {}, walletReviver: Promise [Promise] {} }
...
2023-09-08T01:05:40.347Z SwingSet: ls: v2: Error: D() arguments cannot include a Promise
at construct ()
https://github.com/Agoric/agoric-sdk/actions/runs/6116183603/job/16601003319?pr=8311#step:6:4288
@dckc mergify is not configured on non-master branches |
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 was this file updated? It has impact on other bundles that won't be published.
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.
And most critically, does anything depend upon this behavior change appearing in a vat that isn't being updated? One concern with packages/internal
is that it implies we can change both sides of an interface at the same time, but those changes must be deployed to be available, and deployment isn't automatic.
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.
most critically, does anything depend upon this behavior change appearing in a vat that isn't being updated?
no.
Why was this file updated?
It was based on feedback from @turadg in the context of #8071 (I'm struggling to find the exact comment; might have been over audio).
It has impact on other bundles that won't be published.
Since other bundles aren't being deployed, that's in some ways not a problem, at least not for this particular walletFactory upgrade.
But I'm sympathetic to the concern, and the change is largely stylistic, so I suppose I'm willing to undo, provided you and @turadg agree that's best.
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 recall the specifics of the conversation. Probably something about not being surprised by the default value.
I support reverting this change. The ergonomics aren't worth the API break.
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 backing out the change in this file (and related downstream stuff).
But I do need the fakeStorage.getBody()
change in storage-test-utils.js
below.
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.
np, storage-test-utils
is never used in vat code.
This performance optimization avoids all the work of getting an invitation if there aren't sufficient funds for `proposal.give`. fixes: #7098
WIP: note limitation on depositFacet assetKind - feat(smart-wallet): purses for well-known brands - use side table for new purse storage - issuer/brand mutual check - storage faciliteates transition to decentralized issuer introduction - take care with .init() vs. .set()! - diagnosis complicated by obscure "no ordinal" diagnostic - non-vbank asset test tells story in t.log - test: demonstrate how to share brand displayInfo - test: spend before receive non-vbank asset build(smart-wallet): bundle-source devdep SQUASHME: test: bundle handling, IST_UNIT, ... SQUASHME: refactor based on review feedback - XXX move? -> TODO - mutualCheck -> assertMutual with independent failures - hoist getBrandToPurses() - rename to getPurseIfKnownBrand() - inline addIssuer (aka acceptIssuer) - throw on mutualCheck failure SQUASHME: xP fixup receive throw fixup getPurseIfKnownBrand
- mint-ist.sh to pay for publish-bundle adapted from auctioneer-private-args branch - ensure GOV1ADDR is set so we don't give agd too few args and get a weird diagnostic - chore(walletFactory): initHandler / setHandler / upgrading - chore(walletFactory): start -> prepare for compat - chore(game contract): atomicRearrange -> zcf.reallocate() for compat - feat(smart-wallet): publishAgoricBrandsDisplayInfo to vstorage - test(smart-wallet): upgraded walletFactory handles game NFT - install game contract before walletFactory upgrade - move vat-status.mjs to tools/ - move mint-ist, parseProposals to tools/ - chore: split game1 proposal from walletFactory upgrade - chore: move build-walletFactory-upgrade from builders/ to vats/ since vats/ already depends on deploy-script-support - chore: punt zoe noop actions in upgrade-11 - chore: use instancePrivateArgs in upgradeWalletFactory
rebasing on release-mainnet1B, in discussion with @warner (I didn't realize that release-mainnet1B is 1 later than agoric-upgrade-11 until now) |
closes: #8305
refs: #8308 (alternative approach), #8156
Description / Testing / Upgrade Considerations
back-port #8071, #8147 to the release-mainnet1B branch in preparation for upgrading walletFactory by way of a core-eval on top of agoric-upgrade-11.
builders
package that doesn't exist in the mainnet branch.yarn.lock
update due to an additional devDependency in packages/smart-wallet:import-meta-resolve
, and some changes in our coding style.Note: This is a long way from testing that every aspect of walletFactory remains working after an upgrade. It's just the same tests that were judged sufficient to address #8156.
Security / Scaling Considerations
Nothing new here.
Documentation Considerations
A discussion of the upgrade proposal should be shared via community.agoric.com.