Autoclone with failed command needs more communication

[harmony7]

Describing

The CLI has a useful flag --autoclone. However, I’m seeing confusing behavior when using it.

Assuming my service is currently on version 1 (active), if I use --autoclone and I type an invalid command, even something like this:

fastly backend create --autoclone --version=active

I get an error message:

ERROR: the Fastly API returned 400 Bad Request: Name can't be blank, 'address', 'ipv4', 'ipv6', or 'hostname' is required.

Unfortunately by this time it seems the cloning by --autoclone has already happened, so if I follow up with another command:

fastly backend create --autoclone --version=active --name=origin --address=www.example.com

I will end up on version 3.

I get it because I understand the cloning happens separate from the backend create, however the CLI doesn’t say this so I found it confusing. It results in a mismatch between the user's mental model of the state of the service and the actual state.

Proposed fix

More communication can help here. I’m thinking that a stdout message when the new version has been created would help clarify. That way, if an error occurs you can still see that the version has been created even though your desired operation never went through to completion.

[Integralist]

Agreed. This is a confusing experience.

Service versions are immutable so we can't undo the new service version.

We should see if we can validate the flag value before executing the handler logic.

[Integralist]

Might also be worth checking this broadly across the CLI (e.g. any where a new service version might be created).

[kpfleming]

This is a slippery slope, of course.. if we attempt to validate the API input in the CLI before issuing the API request, then we're forever stuck with doing that for every API request. We'd also need to decide whether this belongs in the CLI itself or in go-fastly.

[Integralist]

Yeah we used to have go-fastly AND the CLI validate API inputs but then we removed that sort of logic to avoid being locked to a behaviour that we (go-fastly, CLI) don't control

[kpfleming]

Proposal: what if the CLI 'remembered' that it had autocloned to create a new draft version, and if the subsequent API call failed, it emitted a specific detailed message telling the user what had happened (including the version number of the new draft version)?

[Integralist]

re: proposal -- that works for me I think