This PR makes two changes:
(1) It renames the New-RetryOptionsE to New-RetryOpts, and then it sets New-RetryOptions as the alias of this new CmdLet. I'm proposing this approach over other ones because its simple, and therefore I trust it's reliability. We should be able to remove this alias "hack" once we ship with a PowerShell worker that does not have a built-in SDK.
(2) Adds the Get-DurableTaskResult API. There's 1 change to the API: it now only takes a single task as its input, instead of a list of tasks. This is how I think the API should work in the first place because it makes it equivalent to performing an await on a DF C# task. I'm open to changing my mind on this change.
Relatedly, in order to make this change, I needed to make sure that the Execute method of tasks only generated the backing "actions" of a task once, even if the execute method was called multiple times. If we don't do this, calling Get-DurableTaskResult would have obtain the result and then re-scheduled the task anyways!.
This PR makes two changes: (1) It renames the New-RetryOptionsE to New-RetryOpts, and then it sets New-RetryOptions as the alias of this new CmdLet. I'm proposing this approach over other ones because its simple, and therefore I trust it's reliability. We should be able to remove this alias "hack" once we ship with a PowerShell worker that does not have a built-in SDK.
(2) Adds the Get-DurableTaskResult API. There's 1 change to the API: it now only takes a single task as its input, instead of a list of tasks. This is how I think the API should work in the first place because it makes it equivalent to performing an
awaiton a DF C# task. I'm open to changing my mind on this change.Executemethod of tasks only generated the backing "actions" of a task once, even if the execute method was called multiple times. If we don't do this, callingGet-DurableTaskResultwould have obtain the result and then re-scheduled the task anyways!.