Improve Adjust.processAndResolve method error handling
Hello,
We've noticed using async version of Adjust.processAndResolve() that several situations lead to this method never completing:
- When Adjust SDK is initialisation is invalid (e.g. using an invalid API key)
- When
Adjust.disable()has been called (e.g. when user rejected Adjust from CMP)
Here is a pseudo code example of where is can occur:
func handle(deeplink: URL) async {
guard let adjDeeplink = ADJDeeplink(deeplink: deeplinkURL) else {
redirect(to: deeplink)
return
}
guard let resolvedDeeplink = await Adjust.processAndResolve(adjDeeplink) else { // <- await never completes here, user will never get redirected
// Deeplink resolution failed
redirect(to: deeplink)
return
}
redirect(to: resolvedDeeplink)
}
As we understand this method call should be avoided in the identified situations, we believe it would be safer that the SDK guarantees this method always completes, being successful or not. The reason being: as soon as we decide to work with Adjust link resolution, all the deeplinks and universal links will have to go through this resolution method before being able to handle the user redirection. As other situations could lead to unsuccessful redirection than the 2 we have identified above, we need our app to be able to handle this situation gracefully and avoid the worst case scenario where the user is never redirected.
Would it be possible to improve the processAndResolve method with one of those 2 options?
-
Adjust.processAndResolvereturnsnilwhen the resolution failed for any reason -
Adjust.processAndResolvethrows an error when resolution failed for any reason
Side note: we could not find reference to Adjust.processAndResolve method in documentation, which refers to resolveLinkWithUrl method that seems to no longer exist in latest Adjust SDK version.
Thanks for you support.
Same problem. Unshortened URLs are almost always returned, but when I try to expand a shortened URL, the value is not frequently returned with await method.
Hey guys,
Thank you for the report. Is this something you are able to reproduce on your end? Any example of the shortened URL which you send and never get back the resolved URL would be of great help to be able to check this on our end.
Also, @tdesert, thank you for your suggestion, it makes sense and we'll look into adding these changes to cover these cases as well.
@uerceg Could you give me an email account? We are using our company account and would like to give you an example by mail.
Sure thing, you can find it if you check my GitHub profile.
@uerceg Thanks! I sent the email now.