"Data type is not supported as an attribute value" crash
eseay opened this issue · comments
We currently have mParticle v7.16.2 installed in our app via Swift Package Manager, and have been encountering a crash with the message from the issue title periodically.
After doing some investigation into this, we discovered that the problem was us inadvertently passing a value of NSNull() with one of our keys in the customAttributes dictionary of an event. This was occurring due to an incorrectly configured manual implementation of Encodable on one our event representation types (using encode... on an optional property rather than encodeIfPresent). When the NSNull value was passed to the dictionary, it would cause the NSDictionary+MPCaseInsensitive.m:transformValuesToString function to fail on line 75 with an NSAssert.
While the root cause of this crash is indeed an error within our own implementation, I wanted to raise this issue in particular because I would not expect an assertion like this to result in a crash when running in a release build.
I am fairly certain the issue lies in the particular usage of NSAssert vs an assert. I haven't written Obj-C regularly in a few years, but nowadays, I use assert and assertionFailure heavily throughout my Swift code, and they are just ignored in release builds.
To reproduce, simply call: MParticle.sharedInstance().logEvent("testEvent", eventType: .other, eventInfo: ["myKey": NSNull()])
Thanks!
@eseay We're going to look into this issue internally and report back to you when it's been resolved.
@alexs-mparticle Sorry I hadn't seen your reply earlier. We're obviously using a much newer version of mParticle now, and we've published a workaround in our own code, so I can't say for certain if this still happens. I appreciate the team looking into this!
Ran into this issue myself - bit of investigation with the team and came across:
https://forums.swift.org/t/assertions-in-swift-packages/42692
We're currently trying to identify where our dodgy value comes from but workaround for us will be forking the repository and amending the manifest. We started seeing this after we migrated from Carthage to SPM.
Thanks for that information @timsearle! We've updated the SDK with the suggested fix as of version 8.2.1.
@eseay I'm going to go ahead and close this issue, but if you run into additional related problems, please feel free to comment here and we can re-open, or create a new issue.
Re-opening--we actually ran into an issue with 8.2.1 and needed to revert. Please do not attempt to update to that version. (Tag has been deleted but in case you already pulled it down.)
We will still get this fixed in our next release which will likely be 8.2.2--will advise here when that's been released.
Fix for this has been released as 8.3.0. Closing.