removeOperator for fast-usdc #10755
removeOperator for fast-usdc #10755
Conversation
Deploying agoric-sdk with
|
| Latest commit: |
9f3f27b
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://76174888.agoric-sdk.pages.dev |
| Branch Preview URL: | https://10754-removeoperator.agoric-sdk.pages.dev |
| const feedKit = makeFeedKit(); | ||
| const { op1 } = await makeOperators(feedKit); | ||
| const evidence = MockCctpTxEvidences.AGORIC_PLUS_OSMO(); | ||
|
|
||
| // works before disabling | ||
| op1.operator.submitEvidence(evidence); | ||
|
|
||
| op1.admin.disable(); | ||
| await feedKit.creator.removeOperator('op1'); |
There was a problem hiding this comment.
maybe this means makeOperator can lose the awkward admin thing altogether?
There was a problem hiding this comment.
removeOperator calls operatorKit.admin.disable().
What's awkward about it?
There was a problem hiding this comment.
I mean makeOperator in the test file.
agoric-sdk/packages/fast-usdc/test/fast-usdc.contract.test.ts
Lines 227 to 228 in 1f25ee2
There was a problem hiding this comment.
that test no longer needs admin but it's still true that OperatorKit has an admin facet and the operator invitation offer result is an OperatorKit. I'm not sure what changes you propose.
There was a problem hiding this comment.
I suggest that result of makeOperator in the test file should not include an .admin property; the returned value should represent what an operator can do, and operators don't have admin authority.
There was a problem hiding this comment.
I think the change you're asking for is to app, not just tests.
The current design is that operators do get the admin facet of the operator kit. (My recollection from earlier; I'm on a phone now)
Right now that means they can disable themselves. Not a bad thing but I agree they shouldn't get a facet called admin.
So in this PR I'll attenuate the kit to omit admin in the offer result.
refs: #10754
Description
This has a couple fixes for removing operators,
It shouldn't close that issue until it has a scenario test (in /boot). Reviewers, should that come in another PR so this can land or should this include that test?
Security Considerations
Scaling Considerations
Documentation Considerations
Testing Considerations
Upgrade Considerations