What should a platform do if a Service Broker doesn't conform to the spec around Errors

[williammartin]

Heyo, while reading https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#service-broker-errors there are some sections regarding errors and descriptions:

A single word in camel case that uniquely identifies the error condition. If present, MUST be a non-empty string.

and

A user-facing error message explaining why the request failed. If present, MUST be a non-empty string.

I'm curious what behaviour we might expect from a Platform in these circumstances if for example, these fields were left empty. I guess I'm struggling a little bit to understand what the point of the restriction is if we don't require a particular behaviour?

[duglin]

IMO this is defining what a well-behaved implementation is supposed to do, and if it doesn't then someone can (rightfully) say they're non-compliant and ask them to fix it. In some cases, I think, we do say what a receiver of such a non-conformant message should do (mainly just for some level of consistency/interop), but there are cases where the processing flow is out of our control. For example, we can say what a broker should do if the Platform misbehaves because we're in the middle of defining the entire request/response interaction. But, in the case of the broker returning bad data to the Platform, since that's on the HTTP response flow there really isn't much we can mandate w.r.t. what the Platform does - it can't talk back to the Broker to tell it that it messed up - so what the Platform does at that point is really up to it.

To the cases you mentioned... we say it needs to be non-empty so the Platform can reliably present the user with some meaningful information. If the Broker violates the spec then I think the Platform needs to be prepared to handle it (have some default "undefined" string ready to use), but at the same time it should complain to the Broker author about it.

Just my 2 pence

[williammartin]

Thanks @duglin !