-
Notifications
You must be signed in to change notification settings - Fork 460
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
Expanding a product when retrieving a plan causes JSON unmarshalling errors #692
Comments
(The Java SDK has |
Ah, I think it's missing an UnMarshalJSON method. I'll take a crack at it. |
@majelbstoat Nice catch and sorry about the trouble. The solution is to replace the string by a |
ooh, neat. |
wait, no, I don't actually understand 😂. |
@majelbstoat Sorry I could have been clearer! This line says:
This means that when you deserialize a plan we expect Product to be a string. But if you expand it it will be a hash. So instead you should have this line:
This will let stripe-go deserialize the product properly. If a string is returned we will automatically set This works because the |
Bumps [sentry-ruby](https://github.com/getsentry/sentry-ruby) from 5.4.1 to 5.4.2. - [Release notes](https://github.com/getsentry/sentry-ruby/releases) - [Changelog](https://github.com/getsentry/sentry-ruby/blob/master/CHANGELOG.md) - [Commits](getsentry/sentry-ruby@5.4.1...5.4.2) --- updated-dependencies: - dependency-name: sentry-ruby dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Simple repro:
Expected outcome is that a plan is returned. Actual behaviour is:
2018/09/11 15:23:28 json: cannot unmarshal object into Go struct field Plan.product of type string
The following also fails for the same reason.
Current workaround is to just make a second request, but that's kind of wasteful.
I'd submit a PR, but I'm not sure what your preferred approach to supporting both string and expanded return types is.
The text was updated successfully, but these errors were encountered: