In the v2.13 specification, it indicates that the loop process of last operation would be polled for each async operation, but it seems that some test cases (Provision/Update/Deprovision) don't trigger the loop. And the result is that it would fail to update the instance after the async provision operation partly finished, which should not be brokers' fault.
Proposed solution
Considering the specification has defined the polling rules, I suggest we should add this feature in some test cases. For polling interval and duration, it's better to add these two fields in ***.json configuration file, so that vendors can make their own rules.
IMO it’s a big issue to be solved, and I'd love to pull a PR if nobody else wants to.
Problem description
In the v2.13 specification, it indicates that the loop process of last operation would be polled for each async operation, but it seems that some test cases (Provision/Update/Deprovision) don't trigger the loop. And the result is that it would fail to update the instance after the async provision operation partly finished, which should not be brokers' fault.
Proposed solution
Considering the specification has defined the polling rules, I suggest we should add this feature in some test cases. For polling interval and duration, it's better to add these two fields in
***.json
configuration file, so that vendors can make their own rules.IMO it’s a big issue to be solved, and I'd love to pull a PR if nobody else wants to.
@duglin @mattmcneeney @n3wscott @fmui