-
Notifications
You must be signed in to change notification settings - Fork 229
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
Internal JSDoc for fastUSDC and state transition diagram #11061
base: master
Are you sure you want to change the base?
Changes from all commits
9e5f006
52bb555
adb10d2
bfbae77
169d88f
da8b650
a35d91d
643e731
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -59,43 +59,39 @@ sequenceDiagram | |
|
||
# Status Manager | ||
|
||
### Pending Advance State Diagram | ||
### State Diagram | ||
|
||
*Transactions are qualified by the OCW and EventFeed before arriving to the Advancer.* | ||
*Transactions are qualified by the OCW and TransactionFeed before being | ||
delivered to the Advancer.* | ||
|
||
```mermaid | ||
stateDiagram-v2 | ||
[*] --> Observed: observe() | ||
[*] --> Advancing: advancing() | ||
|
||
Advancing --> Advanced: advanceOutcome(...true) | ||
Advancing --> AdvanceFailed: advanceOutcome(...false) | ||
|
||
Observed --> [*]: dequeueStatus() | ||
Advanced --> [*]: dequeueStatus() | ||
AdvanceFailed --> [*]: dequeueStatus() | ||
|
||
note right of [*] | ||
After dequeueStatus(): | ||
Transaction is removed | ||
from pendingTxs store. | ||
Settler will .disburse() | ||
or .forward() | ||
end note | ||
``` | ||
The transactionFeed receives attestations from Oracles, records their | ||
evidence, and when enough oracles agree, (if no risks are identified) | ||
it publishes the results for the advancer to act on. | ||
|
||
The Advancer subscribes (via `handleTransactionEvent`) to events published by | ||
the transactionFeed. When notified of an appropriate opportunity, it is | ||
responsible for advancing funds to fastUSDC payees. | ||
|
||
### Complete state diagram (starting from Transaction Feed into Advancer) | ||
The Settler is responsible for monitoring (via `receiveUpcall`) deposits to the | ||
settlementAccount. It either `disburse`s funds to the Pool (if funds were | ||
`advance`d to the payee), or `forwards` funds to the payee (if pool funds | ||
were not `advance`d). | ||
|
||
```mermaid | ||
stateDiagram-v2 | ||
state Forwarding <<choice>> | ||
state AdvancingChoice <<choice>> | ||
|
||
Observed --> AdvanceSkipped : Risks identified | ||
Observed --> Advancing : No risks, can advance | ||
Observed --> Forwarding : No risks, Mint deposited before advance | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
We should expand this more because it's no longer accurate. An invariant is that the contract never There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree that all that happens, and it complicates our process, but if it complicates the state transitions, it's not obvious to me how it should be represented. AFAICT, the state transitions are unaffected by all of this. Should we represent those possibilities more explicitly in the states? Perhaps I could add a note on the choice node listing the conditions that the code pays attention to to decide whether and when to attempt to forward. |
||
Forwarding --> Forwarded | ||
Advancing --> Advanced | ||
Advanced --> Disbursed | ||
|
||
Forwarding --> Forwarded : settler.forward() succeeds | ||
Advancing --> AdvancingChoice | ||
AdvancingChoice --> Advanced : advancer's transferHandler detects success | ||
Advanced --> Disbursed : settler.disburse() | ||
AdvanceSkipped --> Forwarding : Mint deposited | ||
AdvanceFailed --> Forwarding : Mint deposited | ||
Advancing --> AdvanceFailed | ||
Forwarding --> ForwardFailed | ||
``` | ||
AdvancingChoice --> AdvanceFailed : advancer's transferHandler detects failure | ||
Forwarding --> ForwardFailed : settler.forward() fails | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. [possible duplicate, I thought I wrote this already.] The old There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. choice nodes render just as the diamond, not with their label |
||
``` |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,5 @@ | ||
/** @file main export: @see {prepareSettler} */ | ||
|
||
import { AmountMath } from '@agoric/ertp'; | ||
import { assertAllDefined, makeTracer } from '@agoric/internal'; | ||
import { CosmosChainAddressShape } from '@agoric/orchestration'; | ||
|
@@ -105,6 +107,17 @@ export const stateShape = harden({ | |
}); | ||
|
||
/** | ||
* The Settler is responsible for monitoring (using receiveUpcall) deposits to | ||
* the settlementAccount. It either "disburses" funds to the Pool (if funds were | ||
* "advance"d to the payee), or "forwards" funds to the payee (if pool funds | ||
* were not advanced). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's worth mentioning:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I mentioned the registration. In Settler,
The first of these doesn't seem to match what the second bullet says. Would you rephrase? |
||
* | ||
* Funds are forwarded | ||
* | ||
* `receivUpcall` is configured to receive notifications in | ||
* `monitorMintingDeposits()`, with a call to | ||
* `settlementAccount.monitorTransfers()`. | ||
* | ||
* @param {Zone} zone | ||
* @param {object} caps | ||
* @param {StatusManager} caps.statusManager | ||
|
@@ -227,7 +240,6 @@ export const prepareSettler = ( | |
self.addMintedEarly(nfa, amount); | ||
return; | ||
|
||
case PendingTxStatus.Observed: | ||
case PendingTxStatus.AdvanceSkipped: | ||
case PendingTxStatus.AdvanceFailed: | ||
return self.forward(found.txHash, amount, EUD); | ||
|
@@ -275,10 +287,12 @@ export const prepareSettler = ( | |
} | ||
}, | ||
/** | ||
* If the EUD received minted funds without an advance, forward the | ||
* funds to the pool. | ||
* | ||
* @param {CctpTxEvidence} evidence | ||
* @param {CosmosChainAddress} destination | ||
* @returns {boolean} | ||
* @throws {Error} if minted early, so advancer doesn't advance | ||
* @returns {boolean} whether the EUD received funds without an advance | ||
*/ | ||
checkMintedEarly(evidence, destination) { | ||
const { | ||
|
@@ -313,6 +327,9 @@ export const prepareSettler = ( | |
asMultiset(mintedEarly).add(key); | ||
}, | ||
/** | ||
* The intended payee received an advance from the pool. When the funds | ||
* are minted, disburse them to the pool and fee seats. | ||
* | ||
* @param {EvmHash} txHash | ||
* @param {NatValue} fullValue | ||
*/ | ||
|
@@ -344,6 +361,8 @@ export const prepareSettler = ( | |
statusManager.disbursed(txHash, split); | ||
}, | ||
/** | ||
* Funds were not advanced. Forward proceeds to the payee directly. | ||
* | ||
* @param {EvmHash} txHash | ||
* @param {NatValue} fullValue | ||
* @param {string} EUD | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -209,7 +209,6 @@ export const prepareStatusManager = ( | |
skipAdvance: M.call(CctpTxEvidenceShape, M.arrayOf(M.string())).returns(), | ||
advanceOutcomeForMintedEarly: M.call(EvmHashShape, M.boolean()).returns(), | ||
advanceOutcomeForUnknownMint: M.call(CctpTxEvidenceShape).returns(), | ||
observe: M.call(CctpTxEvidenceShape).returns(), | ||
hasBeenObserved: M.call(CctpTxEvidenceShape).returns(M.boolean()), | ||
deleteCompletedTxs: M.call().returns(M.undefined()), | ||
dequeueStatus: M.call(M.string(), M.bigint()).returns( | ||
|
@@ -311,14 +310,6 @@ export const prepareStatusManager = ( | |
publishEvidence(txHash, evidence); | ||
}, | ||
|
||
/** | ||
* Add a new transaction with OBSERVED status | ||
* @param {CctpTxEvidence} evidence | ||
*/ | ||
observe(evidence) { | ||
initPendingTx(evidence, PendingTxStatus.Observed); | ||
}, | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks. I think we also need some cleanup in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks. |
||
/** | ||
* Note: ADVANCING state implies tx has been OBSERVED | ||
* | ||
|
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 it worth mentioning how
receiveUpcall
works? The Settler also needs to register a handler for thesettlementAccount: OrchestrationAccount
- that's what sets up the events: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 think that goes in the state diagram, but I can put it in the class comment.