-
Notifications
You must be signed in to change notification settings - Fork 294
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
Async Adid getter never calling the ADJAdidGetterBlock callback #740
Comments
Hey @alessioborraccino, Yes, As explained above, for You not seeing |
Using: XCode: 16.0 Here is the log at first start of the app where it hangs: [Adjust]w: SANDBOX: Adjust is running in Sandbox mode. Use this setting for testing. Don't forget to set the environment to Then it hanges here forever |
Can you try to:
? |
I am having the same issue |
Hey @saadaamir, Did you try the suggested steps? If yes, would it be possible to get the SDK verbose logs from the test run (and of course, feel free to omit any sensitive data from there)? |
@uerceg On changing the implementation to Pod everything started to work as expected. Hope this helps! @alessioborraccino |
@saadaamir Thank you for letting us know, and that's extremely odd what you've faced (that this works for you if you use CocoaPods and it doesn't work with SPM). It really shouldn't be like that (it should work in the same way both ways). We will take a look at this claim on our end to see if there's any inconsistency between the two ways of integrating the SDK. |
@saadaamir thanks for the tip, unfortunately going back to pods is not an option for us.
Once in this state it never moves forward anymore. |
Hey @alessioborraccino, Thanks for getting back to us. Reason why this is happening is following:
What you are seeing in your steps 5-6 is the bullet point 2 from above. Once you reinstall app on your test device, you're wiping our internally stored information which makes SDK aware that it has tracked session before. So upon relaunching the app, SDK will immediately try to send session request first. However, having in mind that your test device has successfully sent session request seconds/minutes ago, our backend will reject it as being too frequent, effectively causing scenario from bullet point 2. I would say that this should be pretty edge case in production (effectively happening only to your users who have opened their apps and then after that managed to reinstall your app and open it in less than 30 minutes). However, we'll check into adding this change so that Hopefully this clears things up a bit. In case you have additional questions, feel free to ping. |
@uerceg , thanks for looking into it. I am not sure i understand why top level parameters for the json are the issue here, but it doesn't matter too much to us, if you understand the issue it's already a good step forward. It's obvious that we can't update the sdk in the app until this is resolved, for 2 reasons:
Considering this, please let me know when it's solved, as we wanted to go forward with testing the update with some weeks before xmas, to make sure everything works correctly. |
Sure thing, we'll keep you posted. 👌 |
Hi,
While attempting to migrate to adjust 5 from 4, i encountered an issue:
These methods became asynchronous:
Since we need to get the adid, we try to fetch it and store it , between other times, also at a certain time after the initialisation of the SDK.
Unfortunately, after the session and attribution are assigned, if ADID is still nil, trying to access it with the new asynchronous functions results in a hang forever, because the completion callback never gets called.
Could you please double check this, and help me out either with a fix or a work around solution?
Alessio Borraccino from Autoscout24
The text was updated successfully, but these errors were encountered: