https://www.ory.sh/ logo
Join Slack
Powered by
What is the proper way to parse API error messages...
# talk-kratos
p
What is the proper way to parse API error messages using 
client-go
? The API documents mention 
errorGeneric
but the 
ErrorGeneric
struct in 
client-go
does not match the structure so it fails to json unmarshal.
Here's the body of the error
Copy code
{
  "error": {
    "code": 409,
    "status": "Conflict",
    "message": "Unable to insert or update resource because a resource with that value exists already"
  }
}
And GenericError struct is
Copy code
type GenericErrorContent struct {
    Debug *string `json:"debug,omitempty"`
    Error *string `json:"error,omitempty"`
    ErrorDescription *string `json:"error_description,omitempty"`
    Message *string `json:"message,omitempty"`
    StatusCode *int64 `json:"status_code,omitempty"`
}
Looks like it's been updated for v1.15: https://github.com/ory/client-go/blob/master/model_generic_error.go. Yet this is what I'm using.
go get <http://github.com/ory/client-go|github.com/ory/client-go>
is not pulling the v1.15 tag. Anyone know why that would be?
I download the src from here: https://github.com/ory/client-go/releases/tag/v1.1.5. This has the updated struct. But 
go get <http://github.com/ory/client-go@v1.15|github.com/ory/client-go@v1.15>
does not. So frustrating.
I see two versions of the file 
model_generic_error_content.go
Both files say 
API version: v1.1.5
. Yet one has the alpha v0.2 struct and the other has the updated struct.
Something is broken somewhere.
s
@plain-lunch-50969 can you check go.mod for eventual inconsistency? Sometimes there is a problem with go get updating the go.mod
p
<http://github.com/ory/client-go|github.com/ory/client-go> v1.1.5 // indirect
Isn't it odd that I see a file with 
API version: v1.1.5
but v0.2 structs?
Seems like an API generation error instead of a go mod error.
Jesus. 
v1.1.5
vs 
v1.15
s
Yea that looks wrong. I can look into it tomorrow . If you can make an issue in the ory/sdk repo? Please keep in mind: “This code base, including this README, is auto-generated using OpenAPI Generator. If you find bugs in the SDK please check if there is an open issue at OpenAPITools/openapi-generator or ory/sdk already before opening an issue here.”
p
Ok.
s
We try to do a post gen review, but it’s not always on the mark @wonderful-lamp-2357 would you please check into this tomorrow and resolve the issue?
@plain-lunch-50969 we Are in Germany and won’t get this done today.
p
For reference this the file I get with 
go get .... v1.1.5
model_generic_error_content.go
Understood. I know it's late there. Thanks. 🍺
Looks like the api spec has the incorrect struct: https://github.com/ory/client-go/blob/master/api/openapi.yaml#L7035
So somehow the client APIs are not in sync with the kratos server responses.
kratos-client-go
and 
client-go
differ. 
go get <http://github.com/ory/kratos-client-go@v0.11.1|github.com/ory/kratos-client-go@v0.11.1>
pulls down the correct GenericErorContent - but the APIs differ in incompatible ways.
Which is confusing to develop against.
m
Hey Geoff, I think a big part of the confusion is the difference in the clients. I can maybe explain that in short. ---- TLDR: ory-client is the SDK used for Ory Network. kratos-client/hydra-client etc. should be used when self-hosting these services. ---- Since we have a different release cycle on Ory Network (we release to prod very often) we will more often update the ory-client SDK. Ory Kratos on the other hand is on a quarterly release cycly as of now. As such there are some differences in the SDKs. In general they are compatible. But you would have to be on the exact same version of Ory Kratos for the SDK to be totally interchangeable. For example when Ory Network is running Ory Kratos for example from this commit you would have to be on the same exact version of Ory Kratos in your self-hosted deploy. I hope that makes it a bit clearer and let me know if not. If you find any errors or bugs in the SDK, the best course of action is usually to open an issue in ory/sdk or the respective client repo. We can give you some help here of course as well. Thanks 🙂
p
That makes sense, thank you. I would suggest explaining that in large red letters at the start of documentation for both SDKs. The only thing I've seen is a warning that they may not be compatible. This is the warning:
Copy code
The client SDK works with self-hosted Ory services, but it is recommended to use the dedicated client. Read more in the self-hosting documentation for each project under Reference/SDK.
This appears to not be true? The SDKs have different formats and are not compatible, This is the issue I saw, right? Which ory (self-hosted or Ory Network) is the API for? This is also not clear. I don't think it's stated anywhere. This one: https://www.ory.sh/docs/reference/api ?
Looks like the REST API is the Ory Network API. It differs from the kratos-client-go SDK. Please please please make this very clear at the top of the documentation. I've wasted days on this.
m
Right I added that warning, I was hoping it would be enough; clearly it was not 😕 I was also under the assumption that the SDK would generally work when self-hosting and only be different in a few aspects. https://www.ory.sh/docs/reference/api is the reference for all services on Ory Network https://www.ory.sh/docs/kratos/reference/api https://www.ory.sh/docs/hydra/reference/api https://www.ory.sh/docs/keto/reference/rest-api are the references for the individual services They should be the same, if that is not the case for example for the go client you are using, please do open an issue on ory/sdk so we can take a closer look.
p
Thanks for the reply. I would recommend more than a warning! There are or can be differences that are breaking. Things almost working is much worse than not working at all. Maybe even put in a check when using various APIs/SDKs that will fail out of hand if mixing Ory Network/Self-hosted servers and APIs.
m
I created an issue to track it https://github.com/ory/docs/issues/1223 , thanks for the feedback 🙏
p
Thank you and thank the Ory team for all the work you do and give away....
11 Views
Open in Slack
PreviousNext
Powered by