stack.Cancel support in dotnet Automation API

[t0yv0]

Go implementation does SelectStack first, which I think mutates workspace to current stack. Should we do the same for consistency?

Do we want CancelOptions with "OnStandardOutput" etc?

In cases where the operation fails, as in, (1) there is no pending update; (2) it's unsupported on the local workspace, do we signal these with exceptions or error codes?

Testing can be a bit tricky here let me think how to test this.

[t0yv0]

CC @orionstudt

[orionstudt]

I think we should be doing SelectStack first just because that is how all other functionality currently works on WorkspaceStack.

As for the 2 potential errors you mentioned, are those errors the CLI will throw? Perhaps we can just allow those to be caught by CommandException?

[komalali]

I think we should be doing SelectStack first just because that is how all other functionality currently works on WorkspaceStack.

If we do this we'll need to remove it in the 3.0 branch since we're migrating to using the --stack flag instead of SelectStack for all operations. See https://github.com/pulumi/pulumi/pull/6415/files

[orionstudt]

@komalali makes sense - is there a PR that already did that? If not I think we add SelectStack here and whatever PR is switching to using the --stack param would hit them all, including this one

[komalali]

@orionstudt yes, the PR is linked in my comment above but here it again: #6415

[orionstudt]

Roger. Didn't realize it was already merged. Than yea just --stack

[komalali]

FWIW that PR (6415) actually just adds --stack to all RunCommandSync in WorkspaceStack so we don't have to add it to each individual method. And also, that PR is only merged into the 3.0 branch because it's a breaking change for the CLI.

[t0yv0]

Awesome, thank you! I will finish this up tomorrow and try to cook some tests for it especially.

[t0yv0]

Coming back to this. The test is not entirely satisfactory, since it will accept either Destroy or Cancel task failing, but I did not want to check in something intentionally flaky, and I'm not sure how one would make it deterministic. I have verified locally that we at least sometimes hit the branch where Cancel task succeeds in preempting Destroy.

@komalali ready for review 🙏

[komalali]

Nice job with the test, it's a tough one to test for sure!