Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Outdated de-serialization of topic response #80

Open
JonasDoe opened this issue Nov 20, 2023 · 2 comments
Open

Outdated de-serialization of topic response #80

JonasDoe opened this issue Nov 20, 2023 · 2 comments

Comments

@JonasDoe
Copy link

JonasDoe commented Nov 20, 2023

When I run a request for a topic, the response is not deserialized properly. This is b/c the received JSON looks like this:

{
   "data":{
      "_id":"655b65b487e0d9949d7b4b70",
      "_environmentId":"655353e41bf45431ece3fddd",
      "_organizationId":"655353e31bf45431ece3fdd7",
      "key":"83f89d49-1c47-4217-a10c-26386e701bf4",
      "name":"Topic for 1963bc86-945b-4a9c-9728-4b03e752397c",
      "subscribers":[]
   }
}

, but the struct GetTopicResponse doesn't expect data but the inner item:

type GetTopicResponse struct {
	Id             string   `json:"_id"`
	OrganizationId string   `json:"_organizationId"`
	EnvironmentId  string   `json:"_environmentId"`
	Key            string   `json:"key"`
	Name           string   `json:"name"`
	Subscribers    []string `json:"subscribers"`
}

I can imagine this also applies to other requests I did not stumble upon. I could create a PR for GetTopicResponse, but I'm not sure whether that's the way to go or whether you're generating your SDKs from another place. :)

@stonymahony
Copy link

Same problem as with this issue #69 .

@JonasDoe
Copy link
Author

JonasDoe commented Nov 26, 2023

Same problem as with this issue #69 .

I got the impression that the whole SDK is heavily outdated. I found more and more situations where it was firing wrong requests. Additionally, it's often enough hiding errors (esp. HTTP errors) and failure reports from responses. I guess one shouldn't really use it atm.
I hope they will opt for a solution where they generate the client based on the underlying data modell or API, instead of maintaining it manually. This would not solve the issue with swallowed errors, but at least keep the SKD up to date. :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants