Service bindings with invalid names return the same error as service bindings that already exist

[andy-paine]

Issue

Service bindings with an invalid name return same error code as bindings that already exist

Context

Trying to create a binding with a custom (invalid) name such as A binding name with spaces causes CC to return:

{
  "code": 90003,
  "description": "The binding name is invalid. Valid characters are alphanumeric, underscore, and dash.",
  "error_code": "CF-ServiceBindingAppServiceTaken"
}

but this is the same error code as when a binding already exists:

{
  "code": 90003,
  "description": "The app is already bound to the service. The binding name is invalid. App binding names must be unique. The app already has a binding with name 'a-valid-binding-name'.",
  "error_code": "CF-ServiceBindingAppServiceTaken"
}

The CF CLI then assumes that code 90003 corresponds to the second case where the app is already bound to this service see here which is a bit of a misleading error message.

Steps to Reproduce

• Create a service - cf cups a-service -p '{"foo": "bar"}'
• Create an app cf create-app an-app
• Try to bind the app with a bad name - cf bind-service an-app a-service --binding-name "A binding name with spaces"

Expected result

The CLI tells me that this name is invalid

Current result

The CLI thinks that the error is due to the service binding already existing

Possible Fix

Use a different error code for the case of an invalid name vs. an already used name or use a different HTTP code such as 409 Conflict for the case where it already exists

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/177020632

The labels on this github issue will be updated when the story is started.

[sethboyles]

Hmm, looks like a v2 issue. Sadly CLI 7 still uses the v2 endpoint. CLI 8 will use the v3 endpoint, which no longer has this issue. Not sure what the release planning for that looks like...

[sethboyles]

Hi @andy-paine ,

Thanks for reporting this issue!

Unfortunately, it's unlikely we will tackle this issue anytime soon, as it is fixed in V3 and we have a backlog of higher priority issues for the foreseeable future. However, we would be happy to review a PR for this if you (or anyone else) choose to submit one.

Thanks!