You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Multiple invocations of the same flow can concurrently find the localAccount to not be created yet, and attempt to create it.
Description of the Design
We need some provideOnce
Without membranes we’ve used makeAtomicProvider which takes a store and returns a provideAsync that uses a pending promises map to only try making each key once.
Security Considerations
Scaling Considerations
Test Plan
Upgrade Considerations
The text was updated successfully, but these errors were encountered:
IMO we should completely avoid the "shared state" record pattern unless the "provider" of the value is idempotent so that it can be invoked again in new incarnations because the "shared state" is not durable. And even then, I don't see why the "provider" cannot be directly endowed instead.
closes: #10130
## Description
Provide examples of how a contract can have a shared local account, without the race condition of creating it conditionally in a flow.
In the course of this I corrected the `LocalOrchestrationAccount` method signatures (particularly `deposit` not returning the Amount).
### Security Considerations
none, just example code
### Scaling Considerations
none, example code
### Documentation Considerations
Examples are implicit documentation. Can be mined for docs site tutorials if the need arises.
### Testing Considerations
The upgrade test for `send-anywhere` is disabled, but since this just makes a vow there shouldn't be any upgrade interactions.
### Upgrade Considerations
The examples aren't to be deployed.
The remove of `sharedStateRecord` won't affect anything on chain. Same for changing the return of `deposit`.
What is the Problem Being Solved?
This is subject to race conditions:
agoric-sdk/packages/orchestration/src/examples/send-anywhere.flows.js
Lines 44 to 48 in ad7f655
Multiple invocations of the same flow can concurrently find the localAccount to not be created yet, and attempt to create it.
Description of the Design
We need some
provideOnce
Without membranes we’ve used makeAtomicProvider which takes a store and returns a provideAsync that uses a pending promises map to only try making each key once.
Security Considerations
Scaling Considerations
Test Plan
Upgrade Considerations
The text was updated successfully, but these errors were encountered: