-
Notifications
You must be signed in to change notification settings - Fork 214
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(ertp): ertp on zones #7116
Conversation
Datadog ReportBranch report: ✅ |
8ac1531
to
241ec12
Compare
1ec6ade
to
e1b781a
Compare
ba481f6
to
667bfb0
Compare
5e44278
to
25ac290
Compare
Datadog ReportBranch report: ✅ |
25ac290
to
c5b54db
Compare
a0ef385
to
2c74cfc
Compare
eeae1bd
to
46ca164
Compare
*/ | ||
/** @typedef {import('@agoric/zone').Zone} Zone */ | ||
|
||
// TODO Type InterfaceGuard better than InterfaceGuard<any> |
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.
Need help. Finally resorted to any
after everything else I tried failed. I don't understand why this problem arose in this PR but not prior to this PR.
I got rid of all the @typedef
s in case it could help with this, which it did not. But I left the non-@typedef form in anyway because it is now our recommended practice. Preserves type info better in the IDE.
const { Fail } = assert; | ||
|
||
// TODO Type InterfaceGuard better than InterfaceGuard<any> |
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.
Need help. Finally resorted to any
after everything else I tried failed. I don't understand why this problem arose in this PR but not prior to this PR.
I got rid of all the @typedef
s in case it could help with this, which it did not. But I left the non-@typedef form in anyway because it is now our recommended practice. Preserves type info better in the IDE.
f7246b4
to
cf5b231
Compare
af26446
to
b252dcb
Compare
cf5b231
to
bb984c9
Compare
bb984c9
to
8b6fd8b
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.
LGTM.
one question that's more about zones and doc than about this PR.
const recoverySet = makeScalarBigSetStore('recovery set', { | ||
durable: true, | ||
}); | ||
const recoverySet = issuerZone.detached().setStore('recovery set'); |
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.
What does detached()
do? Is there any documentation?
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.
detached()
is how you ask that a new one always be made, even if it is a durable zone. Without detach()
, issuerZone.setStore('recovery set')
would reuse a 'recovery set'
entry in issuerZone
if there is one, and register the newly made one there otherwise. IOW, detached()
is the new way to say make*SetStore
rather than provide*SetStore
.
@michaelfig , I leave the documentation question to you. Thanks.
8b6fd8b
to
a7e3695
Compare
a7e3695
to
6558152
Compare
6558152
to
85e997d
Compare
closes: #XXXX
refs: #8021 #8965 #8977 #8779
Description
ERTP predates both durability and zones. Before zones, it was made durable using baggage-based abstractions. We want to start shifting in general from baggage-based durability to zone-based parameterizability, so that the same parameterizable abstraction can be run in different storage regimes (heap, virtual, durable).
However, the public exports of @agoric/ertp are not changed by this PR. These are the issuer making / preparing / upgrading functions to be invoked from outside @agoric/ertp, and remain parameterized by baggage as of this PR. Later PRs may also directly expose functions parameterized by zones, but this PR does not take that step. Thus, this PR by itself does not yet enable users of @agoric/ertp to parameterize issuer creation by zone.
Security Considerations
none
Scaling Considerations
none
Documentation Considerations
none
Testing Considerations
Aside from upgrade testing, nothing special. Because the publicly exported API of @agoric/ertp has not changed, nothing outside of this package needs new tests. The fact that CI runs without such modification supports that.
Likewise though less obviously for the tests inside @agoric/ertp. The fact that the change to internal APIs did not cause us to revise any tests within the package means that there are no unit tests that are using those internal APIs. A bit of a surprise, but not cause to change that in this PR.
Upgrade Considerations
We believe we are using zones in a sufficiently literal analog to how we used to use baggage that this PR should not cause or need any change to durable state. If true, it should have no effect on upgrade. But this has not yet been tested. I would appreciate help in figuring out how to test that this PR is upgrade neutral.