-
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
A3p test zcf bundle cap #8911
A3p test zcf bundle cap #8911
Conversation
3e544f5
to
cc74195
Compare
{ | ||
"agoricProposal": { | ||
"type": "/agoric.swingset.CoreEvalProposal", | ||
"source": "submission" |
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 the source
needs to be subdir
, but I'm not sure
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.
It worked just fine this way. Was the "need" you refer a style rule, or is the fact that it works sufficient?
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.
submission
isn't a valid value:
https://github.com/Agoric/agoric-3-proposals/blob/c6e52be97d9c5b77abf72f2ab8896264b398ac47/packages/synthetic-chain/src/cli/proposals.ts#L21-L29
but the logic currenctly doesn't validate params; if it's not 'build'
then it assumes 'subdir'
:
https://github.com/Agoric/agoric-3-proposals/blob/c6e52be97d9c5b77abf72f2ab8896264b398ac47/packages/synthetic-chain/src/cli/build.ts#L36-L37
so please change it to subdir
0429a58
to
5298932
Compare
options, | ||
) => { | ||
console.log('probeZcfBundle start'); | ||
const { zoeRef, zcfRef, walletRef } = options.options; |
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 still confused how these options can get passed in. The way things are structured now, the submission is prepared before a3p proposals are run. However I think this proposal does not actually need to generate any bundle, so the submission could be manually written, with the template mechanism used to fill the probed bundle refs?
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 you're right. My current belief is that I want to cite the Zoe and ZCF bundles that will have been included in upgrade-15. I want to do a null upgrade of Zoe to trigger reversion to a stored ZCF bundle. If I can then do a null upgrade to a contract vat (e.g. WalletFactory) then I can compare the ZCF bundle used to the ZCF bundleID just used in upgrade-15.
So I'm looking for how I can find out those bundleIDs to use with the new (very clean!) template mechanism.
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.
@turadg added a check so if the bundle has already been installed, it doesn't do it again. Including these bundle IDs in the manifest is necessary so I can have them to request an upgrade.
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 understand how that's relevant. I actually don't understand why this test needs to install any new bundle ?
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 mean I understand how one option is to do a full generation of core eval scripts and bundles, but I thought from the description we just wanted to "restart" the contracts. I suppose we may want to upgrade ZCF since the test checks it uses the new version
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.
restarting the contracts would be fine.
When I used restartContract()
without a bundleID, in place of E(walletAdminFacet).upgradeContract(walletRef.bundleID, privateArgs);
, I got an error from the kernel that implied that it was trying to upgrade to an earlier version of the contract. checkAndUpdateFacetiousness()
complained that I was trying to remove a facet, which would only make sense if walletFactory was trying to upgrade from a relatively modern version to the version on chain. I'll file a bug to investigate restartContract()
.
Since the only productive way to upgrade the wallet factory was using upgradeContract()
, I needed a bundleId.
With ZCF, I need to pass the bundleID to E(zoeConfigFacet).updateZcfBundleId(zcfRef.bundleID);
to tell Zoe to use a particular version of ZCF when upgrading the contracts. The point of this test is to validate that #8807 correctly fixes Zoe to store the ZCFBundleID
. Before that PR, it clearly was not.
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.
With the fix in commit 5a30b2d877
, I was able to revert to restartContract
for the second restart, but the first still needs to be an upgrade (in the test) so that we can tell whether it is using the original bundleId or the newly provided one.
edcf90e
to
66e3202
Compare
66e3202
to
887615c
Compare
219f9c2
to
d7ba684
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'm still pretty confused by what this test tries to do. We should sync up
await E(zoeInstanceAdmin).repairContractCompletionWatcher(); | ||
console.log(`Repaired contract completion watcher`); | ||
// We don't wait because it's a cross-vat call (to Zoe) that can't be | ||
// completed during this vat's start-up | ||
E(zoeInstanceAdmin) | ||
.repairContractCompletionWatcher() | ||
.catch(() => {}); |
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.
This is not strictly a testing change anymore, right?
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.
I'd guess you're hinting that I should change something, presumably the commit logs, but I don't understand their impact. Is it sufficient that the latest commit has a feat
tag, or do I need to change the PR's title or something else? Do I need to eventually need to check it in as a merge rather than a squash, or is there something else to be careful of?
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 main problem is that this change is in a commit titled test:
. This change should be in a separate commit, before the 'test' commit, describing this change in behavior.
The PR title says "test" but it's normal for other changes to be made to support a testing requirement. The problem is when the changelog leaves those changes out.
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 commit makes two changes. One is the fix to startInstance.js
. The other is a change to the test probe to take advantage of the fix and demonstrate that it fixes the problem. That second change has to update the test, so it can't precede it. I think it's important that the fix and the revelation of its effectiveness stay together.
If I amend the commit to call it a fix
, and remember to not squish, would that be sufficient to update the changelog? If not how would you recommend I address 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 think it's important that the fix and the revelation of its effectiveness stay together.
Up to you.
If I amend the commit to call it a fix, and remember to not squish, would that be sufficient to update the changelog?
Yes
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
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.
Looks like it's still in a "test" commit.
d7ba684#diff-8dcfebb96abffde204086c5d660142e0c4c74a7bac0800f7c18447e0baad1979R472-R477
const { adminNode, root: zoeRoot } = await E(vatStore).get('zoe'); | ||
const zoeConfigFacet = await E(zoeRoot).getZoeConfigFacet(); | ||
|
||
// STEP 1: restart WF; it'll use the newest ZCF ////////////////// |
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.
newest
is ambiguous here, as it's not the zcf bundle that is being installed just 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.
yeah, just the most recent known to Zoe. updated.
options, | ||
) => { | ||
console.log('probeZcfBundle start'); | ||
const { zoeRef, zcfRef, walletRef } = options.options; |
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 mean I understand how one option is to do a full generation of core eval scripts and bundles, but I thought from the description we just wanted to "restart" the contracts. I suppose we may want to upgrade ZCF since the test checks it uses the new version
await evalBundles(SUBMISSION_DIR); | ||
|
||
const detailsAfter = await getVatDetails('walletFactory'); | ||
t.true(detailsAfter.incarnation >= 3, 'wf incarnation after must be >= 3'); |
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.
t.true(detailsAfter.incarnation >= 3, 'wf incarnation after must be >= 3'); | |
t.true(detailsAfter.incarnation == detailsBefore.incarnation + 1, 'wf incarnation must increase'); |
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
'getManifestForProbeZcfBundleCap', | ||
{ | ||
zoeRef: publishRef(install('@agoric/vats/src/vat-zoe.js')), | ||
zcfRef: publishRef(install('@agoric/zoe/src/contractFacet/vatRoot.js')), |
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 can't zcfRef
be the only ref, with a dummy implementation?
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.
WalletRef: The fix in startInstance
below wasn't present the previous time that the walletFactory was upgraded, so Zoe didn't remember the bundleId as it should have.
ZoeRef: adminNode.upgrade() requires a bundleCap. I'd be happy to re-use the already known one. This seems to be the most straightforward way to get it.
await E(zoeInstanceAdmin).repairContractCompletionWatcher(); | ||
console.log(`Repaired contract completion watcher`); | ||
// We don't wait because it's a cross-vat call (to Zoe) that can't be | ||
// completed during this vat's start-up | ||
E(zoeInstanceAdmin) | ||
.repairContractCompletionWatcher() | ||
.catch(() => {}); |
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 main problem is that this change is in a commit titled test:
. This change should be in a separate commit, before the 'test' commit, describing this change in behavior.
The PR title says "test" but it's normal for other changes to be made to support a testing requirement. The problem is when the changelog leaves those changes out.
a526621
to
97460a6
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 left some requests. I'll review again when it's rebased on master or #9004
2bd8f2f
to
d2ca475
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.
The commits can be cleaned up a bit but not a blocker
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.
this should be squashed into the previous.
@@ -0,0 +1,37 @@ | |||
/* eslint-disable @jessie.js/safe-await-separator */ |
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 this isn't doing anything. also the best remedy is await null
instead of suppression
d2ca475
to
afa0803
Compare
75a6159
to
bcc0aa6
Compare
bcc0aa6
to
003ed74
Compare
@gibson042 commit |
refs: #9246 ## Description Add a proposal to upgrade the ZCF bundle only, and run it as a core proposal during chain software upgrade. This is necessary for #9246 but not sufficient as the release also needs to include the fix from #8911. ### Security Considerations None ### Scaling Considerations None ### Documentation Considerations None ### Testing Considerations Will be tested end to end (make sure smart wallet can be upgraded) in #9206 ### Upgrade Considerations @gibson042 must do a partial cherry-pick of 72c7574#diff-8dcfebb96abffde204086c5d660142e0c4c74a7bac0800f7c18447e0baad1979 (the `zcfZygote.js` change) in the release-15 branch. Will be part of that chain software upgrade.
This fix is cherry-picked from #8911 for upgrade 15
This fix is cherry-picked from #8911 for upgrade 15
This fix is cherry-picked from #8911 for upgrade 15
This fix is cherry-picked from #8911 for upgrade 15
Created by following the [pending MAINTAINERS.md](https://github.com/Agoric/agoric-sdk/pull/9235/files?short_path=39da3bd#diff-39da3bd6270d44ea37b6ed50bd42eeb9d93ac5e1639645871a69cbe08cbe29de), branching from dev-upgrade-15. NOTE: [scripts/have-news](https://github.com/Agoric/agoric-sdk/blob/master/scripts/have-news) has an undocumented dependency upon src-prefix="a" that was disrupted by my local [`diff.mnemonicPrefix=true`](https://git-scm.com/docs/diff-config/2.9.5#Documentation/diff-config.txt-diffmnemonicPrefix) configuration, resulting in empty output until I tracked down the issue. I've opened #9269 to track that. ## Packages that have NEWS.md updates ```diff --- c/golang/cosmos/CHANGELOG.md +++ w/golang/cosmos/CHANGELOG.md @@ -3,6 +3,21 @@ All notable changes to this project will be documented in this file. See [Conventional Commits](https://conventionalcommits.org) for commit guidelines. +## [0.35.0-u15.0](https://github.com/Agoric/agoric-sdk/compare/@agoric/cosmos@0.35.0-u14.1...@agoric/cosmos@0.35.0-u15.0) (2024-04-20) + + +### Features + +* upgrade zcf: install bundle and call updateZcfBundleId() ([74662d7](74662d7)), closes [#9250](#9250) +* **cosmos:** Next upgrade is `agoric-upgrade-15` ([6a84bb1](6a84bb1)) + + +### Bug Fixes + +* various fixes and features for u15 ([21e6f7c](21e6f7c)) + + + ## [0.35.0-u14.1](https://github.com/gibson042/agoric-sdk/compare/@agoric/cosmos@0.35.0-u14.0...@agoric/cosmos@0.35.0-u14.1) (2024-03-12) --- c/packages/smart-wallet/CHANGELOG.md +++ w/packages/smart-wallet/CHANGELOG.md @@ -3,6 +3,20 @@ All notable changes to this project will be documented in this file. See [Conventional Commits](https://conventionalcommits.org) for commit guidelines. +### [0.5.4-u15.0](https://github.com/Agoric/agoric/compare/@agoric/smart-wallet@0.5.4-u14.1...@agoric/smart-wallet@0.5.4-u15.0) (2024-04-20) + + +### Features + +* **smart-wallet:** tryExitOffer reclaims withdrawn payments ([6f01f63](6f01f63)) + + +### Bug Fixes + +* in SmartWallet, if invitation is invalid, don't process offer ([29078f7](29078f7)) + + + ### [0.5.4-u14.1](https://github.com/Agoric/agoric/compare/@agoric/smart-wallet@0.5.4-u14.0...@agoric/smart-wallet@0.5.4-u14.1) (2024-03-12) **Note:** Version bump only for package @agoric/smart-wallet --- c/packages/vats/CHANGELOG.md +++ w/packages/vats/CHANGELOG.md @@ -3,6 +3,15 @@ All notable changes to this project will be documented in this file. See [Conventional Commits](https://conventionalcommits.org) for commit guidelines. +### [0.15.2-u15.0](https://github.com/Agoric/agoric-sdk/compare/@agoric/vats@0.15.2-u14.1...@agoric/vats@0.15.2-u15.0) (2024-04-20) + + +### Features + +* upgrade zcf: install bundle and call updateZcfBundleId() ([74662d7](74662d7)), closes [#9250](#9250) + + + ### [0.15.2-u14.1](https://github.com/Agoric/agoric-sdk/compare/@agoric/vats@0.15.2-u14.0...@agoric/vats@0.15.2-u14.1) (2024-03-12) **Note:** Version bump only for package @agoric/vats --- c/packages/zoe/CHANGELOG.md +++ w/packages/zoe/CHANGELOG.md @@ -3,6 +3,15 @@ All notable changes to this project will be documented in this file. See [Conventional Commits](https://conventionalcommits.org) for commit guidelines. +### [0.26.3-u15.0](https://github.com/Agoric/agoric-sdk/compare/@agoric/zoe@0.26.3-u14.0...@agoric/zoe@0.26.3-u15.0) (2024-04-20) + + +### Bug Fixes + +* fix ZCF to not await in first crank ([8e289fd](8e289fd)), closes [#8911](#8911) + + + ### [0.26.3-u14.0](https://github.com/Agoric/agoric-sdk/compare/@agoric/zoe@0.26.3-u13.0...@agoric/zoe@0.26.3-u14.0) (2024-02-27) ```
refs: #8868
Description
An a3p-integration test for #8807.
Security Considerations
N/A
Scaling Considerations
N/A
Documentation Considerations
N/A
Testing/Upgrade Considerations
This is a test that a bug fix had the appropriate effect.
The test takes advantage of the fact that the
vatInfo
held in swingstore (and returned bygetVatDetails()
in synthetic-chain) gives the bundleId of the ZCF in a contract vat rather than the bundleID of the contract itself.