-
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
Support slices in event.GetObjValue
and add tests
#506
Conversation
Modifies `event.GetObjValue` so that when specifying additional keys to descend into, it's now possible to specify integer keys if the target object is a slice of type `[]interface{}` (which should be what anything coming out of event data deserializes to). I initially expressed some concern about expanding this interface, but given that the previous behavior would have been an outright panic, I changed my mind and don't think it's too bad to add support for this given that it's been requested by a user. Fixes #503.
event_test.go
Outdated
// cases. | ||
assert.Panicsf(t, func() { | ||
event.GetObjValue("slice", "string_key") | ||
}, "Cannot access nested slice element with non-integer key: %s", "bad_key") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm likely missing something since the tests are passing, but shouldn't the assert expect "string_key"
, not "bad_key"
?
I left a question in a comment, but it's likely just me missing something. lgtm! (On an unrelated note, it looks like tests are failing on go-tip.) |
Thanks OB. I'm glad you noticed that testing problem — it turns out that what I really wanted was |
And good catch on go-tip. I think the patch in #508 will fix it. |
Released as 28.9.0. |
Modifies
event.GetObjValue
so that when specifying additional keys todescend into, it's now possible to specify integer keys if the target
object is a slice of type
[]interface{}
(which should be what anythingcoming out of event data deserializes to).
I initially expressed some concern about expanding this interface, but
given that the previous behavior would have been an outright panic, I
changed my mind and don't think it's too bad to add support for this
given that it's been requested by a user.
Fixes #503.
r? @ob-stripe
cc @stripe/api-libraries