Cli-microsoft365: New command: Flow remove

[VelinGeorgiev]

flow remove [options]

Removes specified flow

|Options||
|---|---|
|-n, --name <name>|The name of the Microsoft Flow to remove
|-e, --environment <environment>|The name of the environment for which to remove flow
|--asAdmin|Set, to remove the Flow as admin
|--confirm|Confirms deletion

Implementation similar to the Flow-Remove and Flow-AdminRemove cmdlets in PowerShell flow. more information here https://docs.microsoft.com/en-us/power-platform/admin/powerapps-powershell

[garrytrinder]

Hey @VelinGeorgiev 👋🏻 I'd be happy to pick this up 👍🏻

[VelinGeorgiev]

All yours @garrytrinder ! Thank you!

[garrytrinder]

@VelinGeorgiev are you happy for me to change the confirm description on this command to Don't prompt for confirmation ?

This keeps it consistent with other remove commands such as teams channel remove.

[waldekmastykarz]

Good idea @garrytrinder 👍

[VelinGeorgiev]

Yes. Please do. Thanks!

[garrytrinder]

Looks like I've stumbled across a bug in the API, when you pass an invalid Flow Id in the HTTP Delete, you get a '204 No Content' response instead of a 404 or error code 🤔

Any idea on how to capture this in a test?

[waldekmastykarz]

You could check the response code of the HTTP response from the API. I'm not sure if we're doing it anywhere already, but you could see if you can get access to the full response object and its properties and define an extra case where a 204 response is considered an error rather than a success. This would first need to be implemented in the command and then verified in the tests.

[garrytrinder]

@waldekmastykarz thinking about this a little more, I could do a GET before the DELETE as a validation step, passing an invalid Flow Id into the GET does return a 404 Not Found.

I think this would be a better approach rather than checking for the 204 No Content as the DELETE will then only happen if the resource does exist and I can confirm that with less code changes.

Interestingly, I posted this issue on Twitter and there was some debate as to whether the 204 No Content response is actually a valid one for this scenario. For me 204 No Content response is saying 'I have successfully DELETE the resource, but I have no body to send back to you", where it should be a 404 Not Found, "I cannot successfully DELETE the resource as I cannot find it, which should be thrown here. Do you agree?

[waldekmastykarz]

I agree that it should be a 404. If we can capture the 204 instead of issuing a separate request to check if the Flow is there with the same result, then I'd go with the 204 as it allows us to cut the extra request improving the performance of the command.

[garrytrinder]

Thanks for the suggestion @waldekmastykarz 👍🏻

I found the resolveWithFullResponse option that can be added to the request, so I've just implemented a check for the 204 in the success callback to throw an error into the cmd line.

I'll look to get this pushed over the weekend.

[waldekmastykarz]

Nice approach! Looking forward to the PR 👏

[garrytrinder]

Already submitted and ready for review 👍🏻

[waldekmastykarz]

Hero! 😄

[garrytrinder]

APi bug has been reported to Azure Management API team via email

[garrytrinder]

I have heard back from Microsoft on the 204 response.

I got a response from the Product Team earlier than I anticipated.

It turns out that the default response for deleting an invalid Flow Id is the 204 code response.

I was also informed that the reason for this is due to some security considerations.

I have requested that these considerations be shared and hopefully, I would be made privy to it.

So they are saying that this is not a bug 🤔

[waldekmastykarz]

204 is a success status code, so all is good 👍

[garrytrinder]

Further response from support on this...

1. That the reason for the "204" is to indicate that the request sent was acknowlegded, but no content related to the Flow ID was found
2. That since the request is originating from outside of the Flow environment, "204" is returned as not to reveal sensitive information.