Open mhofman opened 4 months ago
In discussion we realized this might detect false-positives because it will allow stopping at places the kernel won't. As an alternative, we can have bootstrapTests force bridge stalls through the message mocking. @michaelfig and I will pursue that in the context of https://github.com/Agoric/agoric-sdk/issues/9303. I think we should leave this ticket open for some general utilities for async-flow.
Another use case that has recently arisen is the ability to more easily test values piercing the membrane: https://github.com/Agoric/agoric-sdk/issues/9780
What we really want here is to detect any issue (with the contract or with the orchestration framework itself) when an upgrade could happen, aka when external messages come in from outside swingset. For that if a test is structured with a list of inputs from the network, we can simply inject and upgrade at that time. In a perfect world, we would tests both the upgrade and non-upgrade paths, and we would test upgrading any combination of running vats.
A different approach would be to mock the orchestration API so that a single contract using orchestration can be put through a similar simulated upgrade of either orchestration or of the contract vat. That however requires a somewhat faithful mock of the orchestration API.
We likely do not want to test a simulated upgrade at all await points of an async-flow.
Maybe integrate with @gibson042's test pattern for IBC step-by-step play.
What is the Problem Being Solved?
In order to gain confidence in the resumability of orchestrated flows, we need to actually upgrade contracts at different steps of an orchestrated flow.
Description of the Design
One way to do that might be to have a test jig into async flow to enable executing the guest function "step by step".
For retriable, it'd give a way to not fulfil the vow with the result of the retried function, or run the retried function multiple times before fulfilling.
Security Considerations
Scaling Considerations
Test Plan
Upgrade Considerations