-
Notifications
You must be signed in to change notification settings - Fork 5
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
"FetchWithCompletion" is never called during network loss #19
Comments
Thank you for your report. We have investigated the behavior you reported and were unable to reproduce it on a physical device, but a similar one was reproduced on a simulator. It seems the following events are causing the issue:
As a result, the execution of the callback becomes extremely slow (up to 1-2 minutes), and it appears that the callback is not being executed. macOS: 13.3(22E252) Could you please provide the following information for a more detailed investigation?
|
In our case, the issue occurred on our app on physical devices, such as the iPhone 12 Pro (iOS 16.4) and iPhone 14 Pro (iOS 16.3), whereas it worked fine on iOS simulators. Although we checked if the completion handler would be called a few minutes later, it didn't even after 5 minutes. The usage might be a bit different from what you expected us to do, since we don't call Variables.fetch() in AppDelegate, but in the ViewController that loads when launching the app. This is because Variables.fetch() often fails to fetch the data needed to compose crucial parts of the screen, and the app needs to be refreshed manually in that case. The followings are excerpt from the code. // KARTE Utility
func fetchVariables(completion: ((_ isSuccessful: Bool) -> Void)? = nil) {
Variables.fetch(completion: completion)
} // View Model
dispatchGroup.enter()
KarteUtils.shared.fetchVariables { isSuccessful in
if isSuccessful {
// Create model data using the fetched variables.
} else {
// Record errors
}
dispatchGroup.leave()
}
dispatchGroup.enter()
api.fetchSomething (
error: { err in
// Do something
dispatchGroup.leave()
}, success: { entity in
// Do something
dispatchGroup.leave()
})
dispatchGroup.enter()
api.fetchSomething2 (
error: { err in
// Do something
dispatchGroup.leave()
}, success: { entity in
// Do something
dispatchGroup.leave()
})
.
.
dispatchGroup.notify(queue: .main) {
// Wrap up something
} |
Thank you for providing the detailed information. Based on the information, we were able to reproduce the issue on our end as well. We are still investigating the details, but since it only occurs once after launching and does not occur afterward, it seems the following possibilities are highly likely:
Although it is not yet confirmed, we think that the reason why this phenomenon does not occur when the network is active is that a separate thread is launched during communication execution(Variables.fetch()), and the callback is executed in that thread. Based on the above hypothesis, we confirmed that the callback is executed even when the network is disconnected by executing We apologize for any inconvenience this may cause, and thank you for your cooperation. |
Speaking of which, this issue can be reproduced in the case of using a content blocker app, such as AdGuard. We actually realized the malfunction the first time we enabled its DNS protection features. Although the following guide says that the kind of apps don't affect KARTE features, they actually do in some cases as we discovered this time. It would be helpful if the guide could elaborate on these cases. https://support.karte.io/faq/3sYYNDdIOBgfeEtWly62H9 Thanks. |
Expected Behavior
"FetchWithCompletion" is never called in any case of errors.
Current Behavior
"FetchWithCompletion" is never called during network loss. This behavior can be reproduced by enabling Airplane mode on iOS.
Possible Solution
Steps to Reproduce
Variables.fetch(completion:)
SDK Version
KarteVisualTracking x.x.xKarteNotificationServiceExtension x.x.xiOS Version
16.0 or later
Build Environment
Carthage Version x.x.xContext Details
Cannot handle the error at all is some cases.
Logs
Possible Implementation
The text was updated successfully, but these errors were encountered: