-
Notifications
You must be signed in to change notification settings - Fork 22
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
fix: track bq migration for identify profile events with no attributes #702
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -108,15 +108,15 @@ public class DataPipelineMigrationAssistant { | |
guard let trackTaskData: IdentifyProfileQueueTaskData = jsonAdapter.fromJson(taskData) else { | ||
return false | ||
} | ||
if let attributedString = trackTaskData.attributesJsonString, attributedString.contains("null") { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When a profile is identified without any attributes, then the task added to BGQ looks like
In case you want to reproduce the scenario :
But I do see that the fix that you made satisfies this condition too so we are good with the changes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for sharing your expertise here. And thanks for sharing the steps. I think the reason you're seeing the value "null" is a behavior of our sample app's implementation. In the APN sample app, we are only calling Therefore, I think this bug is happening for customers who are calling the Most important thing is that all of these use cases are handled. The test suite is testing it all so we're covered. Thanks for confirming this, too. |
||
migrationHandler.processIdentifyFromBGQ(identifier: trackTaskData.identifier, timestamp: timestamp, body: nil) | ||
return true | ||
} | ||
guard let profileAttributes: [String: Any] = jsonAdapter.fromJsonString(trackTaskData.attributesJsonString!) else { | ||
|
||
// If there are no profile attributes or profile attributes not in a valid format, JSON adapter will return nil and we will perform a migration without the profile attributes. | ||
guard let profileAttributesString: String = trackTaskData.attributesJsonString, let profileAttributes: [String: Any] = jsonAdapter.fromJsonString(profileAttributesString) else { | ||
migrationHandler.processIdentifyFromBGQ(identifier: trackTaskData.identifier, timestamp: timestamp, body: nil) | ||
return true | ||
} | ||
|
||
migrationHandler.processIdentifyFromBGQ(identifier: trackTaskData.identifier, timestamp: timestamp, body: profileAttributes) | ||
|
||
return true | ||
} | ||
|
||
|
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.
could be considered scope creep but i think it would make sense, to cater this as well as its the same issue and can cause the same crash? also would save us from doing another release.
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.
Good call, I think we should handle all these cases in this file instead of waiting for issues to be reported. I'm okay if we don't add tests for them in this PR, but I would like to fix possible issues with similar cases in this file before releasing.
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 considered that, too. I don't anticipate that the register device BQ event will ever have a null attributes string because a device token should always be included in the attributes.
However, as we chatted about yesterday, we want to avoid force optional unwraps in the codebase. So, this extra bit of safety could be a good thing.
I do agree, I would prefer to ship this as far of this fix, too. I'll add a new PR to the stack with this change and we can ship them both together.
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.
Opened a PR in the stack for this #704