In 1.1 it looks like errors were automatically converted to Error objects in the responses received by the node sdk, this meant that responses back to client applications had an array consisting of 2 different types of object in different formats
In 1.2 this changed and as it breaks backward compatibility to existing applications and wasn't something that was announced, backward compatibility was provided within the node sdk itself
There are a couple of choices here on going forward
We could stop converting responses which aren't 200 status to error objects and just return the original responses back to the client application to handle. This would break backward compatibility
We could still convert to an Error object, but ensure that they have the same properties as the original response for now, announce the format as deprecated allowing applications to switch to checking the status field themselves.
In 1.1 it looks like errors were automatically converted to Error objects in the responses received by the node sdk, this meant that responses back to client applications had an array consisting of 2 different types of object in different formats
In 1.2 this changed and as it breaks backward compatibility to existing applications and wasn't something that was announced, backward compatibility was provided within the node sdk itself
There are a couple of choices here on going forward
We could stop converting responses which aren't 200 status to error objects and just return the original responses back to the client application to handle. This would break backward compatibility We could still convert to an Error object, but ensure that they have the same properties as the original response for now, announce the format as deprecated allowing applications to switch to checking the status field themselves.