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
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
The text was updated successfully, but these errors were encountered:
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 #9303. I think we should leave this ticket open for some general utilities for async-flow.
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
The text was updated successfully, but these errors were encountered: