async-flow contracts: patterns for shared state and continuing invitations

[0xpatrickdev]

What is the Problem Being Solved?

As an orchestration contract developer, I would like to be able to write a contract that uses async-flow for continuing invitation offer handlers. The path for this seems unclear until we've carved out some patterns for sharing state between exos.

In a recently written restake contact #9821, it was found that:

• only the initial offerHandler (on the publicFacet) was able to leverage async-flow
• continuing invitations need to be provided through an endowed exo, which requires a guest developer to write host code

In a very WIP commit https://github.com/Agoric/agoric-sdk/compare/7df6abefa6460c5ca9a7acc3575f602c53c75960..ca68722f017e7f6ba9c7a9ce4668eb2b5d089239

• attempting to use async-flow for Restake and CancelRestake handlers (and the WakerHandler)
• coming up short on patterns for sharing state (orchAccount, repeater) in the context of multiple async-flows
  • also coming up short on a pattern to make asyncFlow that target of an invitationMaker
• for now, it offers simplified code that can be leveraged as a starting point for making this real

Here are some recent explorations composing exos and continuingOffers that are somewhat, but not entirely relevant to the task at hand:

• combine-invitation-makers.js (combines already-instantiated exos into a new exo)
• feat: add UpdateValidator and CancelAutoStake invitations to auto-stake-it #9786 (mixes in state and methods at prepare/build time)
  • https://github.com/Agoric/agoric-sdk/pull/9786/files#diff-dfad952e65f0966a7368ec116fcd62856a660e32c582ccf3808add6294985496
  • https://github.com/Agoric/agoric-sdk/pull/9786/files#diff-d3babce7472de0a645326afb00d35f5f71a119f811bbeca5e65093d1f5dc5253R60-R96
• refactor: compose asContinuingOffer #9789 (a different approach to the above)

Description of the Design

TBD

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations

[dckc]

Did you consider / try makeStateRecord()?

The pattern from sendAnywhere.contract.js seems like it would extend to multiple flows straightforwardly.

[mhofman]

makeStateRecord() should be renamed makeGlobalStateRecord(). It only works for endowed state shared between all invocations of a flow, which roughly makes it global like.

[dckc]

I don't understand. It doesn't seem to be global state at all. makeStateRecord() makes a thingy; you pass the thingy around as usual. What am I missing?

[mhofman]

Mark suggested makeSharedStateRecord. The important part in this case is that you pass the recorde during the prepare phase of the flow, and the record is shared by all invocations of the flow.

What this issue requires is state used by multiple flow definition, but more importantly not shared between invocations of the flows. To be more clear, flows A, B and C work with some common state such that invocation A-10 shares state with invocations B-35 and C-42.

In the makeStateRecord case, you have a flow D, where invocation D-1, D-2, D-3 etc all share the same state record.

The endowments mechanism cannot support per invocation objects.

[dckc]

makeSharedStateRecord works for me.

... the prepare phase of the flow ...

I'm struggling to understand that. OrchestrationFlows are top-level functions; we don't prepare them, do we?

[mhofman]

These top level orchestrated functions are used with orchestrate or orchestrateAll which is a prepare action. They are comparable the behavior argument of an Exo that was extracted to top level scope.

[mhofman]

Filed #9832 to capture the need to support exo async-flow methods