Symbolize hash keys inside convert_to_stripe_object_with_params

[mebezac]

Without this, perfectly good hash representations of Stripe classes get turned into generic Stripe::StripeObjects if they happen to have string keys.

[CLAassistant]

All committers have signed the CLA.

[pakrym-stripe]

Hi @mebezac, can you describe the scenario where you encounter this issue?

[mebezac]

Hi @mebezac, can you describe the scenario where you encounter this issue?

When we get a webhook from Stripe, we usually pass the data along to a sidekiq worker. We'll quite often pass event.data.object as an argument to the sidekiq worker. Sidekiq serializes all the parameters to JSON in order to store in redis. (https://github.com/mperham/sidekiq/blob/621cab6f756183607a0a5b7f676020d2b9bf05fd/lib/sidekiq/client.rb#L61-L66). That JSON serialization causes all keys to become strings.

Inside jobs, we sometimes we want to use the familiar/convenient methods that a Stripe object gives us. That means we'll take the data (which has been JSON-serialized) and turn it back into a Stripe object using Stripe::Util.convert_to_stripe_object. For now we've just been making sure to .symbolize_keys the data hash before passing it, but I think it would be nice for this library to accept hashes with string keys so that gotcha doesn't trip anyone else up.

Thanks!

[pakrym-stripe]

Does using JSON.parse(json, symbolize_names: true) help you here?

I'm a bit reluctant to put an extra symbolize_names call in the main SDK path as it does a full copy of the entire object graph. This adds performance penalty for every production customer to enable a pretty narrow use-case.

[mebezac]

@pakrym-stripe thanks for the feedback, how about the most recent commit? All that really matters is the object key when looking up the class to construct, construct_from does a symbolize_names and will handle any remaining string keys.

[pakrym-stripe]

The change looks good but the linter is unhappy.

[pakrym-stripe]

Thank you for contribution @mebezac !