in #513 we removed the brittle list of expected response fields and types. Enforcing these fields and types caused a maintenance headache when the Connect API changed (lots of issues like this).
We don't want to bother with the type enforcement that we used to do, but when working on #513 we did discuss the possibility of determining the expected fields based on Connect's API spec docs. The Connect client surfaces the Connect version (if it's not hidden by the server) which can be used to find the right spec.
Using the spec to ensure we return the expected fields might allow us to return more useful outputs in cases like this.
in #513 we removed the brittle list of expected response fields and types. Enforcing these fields and types caused a maintenance headache when the Connect API changed (lots of issues like this).
We don't want to bother with the type enforcement that we used to do, but when working on #513 we did discuss the possibility of determining the expected fields based on Connect's API spec docs. The Connect client surfaces the Connect version (if it's not hidden by the server) which can be used to find the right spec.
Using the spec to ensure we return the expected fields might allow us to return more useful outputs in cases like this.