Comments (19)
This is a serious issue and a basic one too.You can put a internet check before firing query but what you can do when there is slow internet connection? We really need something working as soon as possible.
from aws-mobile-appsync-sdk-ios.
@NathanaelA
I really need to know if you found any solution for your issue in this comment
#91 (comment)
since I face the same issue even in version 2.12.7
from aws-mobile-appsync-sdk-ios.
Hello @rohandubal
Thanks for updating the SDK. I just tested out and seems like it has been fixed.
When I am firing any AppSync query with no internet available, I am getting the localized error description as "Did not receive a successful HTTP code. Error: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline."
Best,
Anup
from aws-mobile-appsync-sdk-ios.
@NathanaelA Great to hear, and no worries about the confusion! Glad it's working for you now.
from aws-mobile-appsync-sdk-ios.
Hello @Anupsarode @DreamBegin
This is fixed in SDK version 2.7.0
Please try it out and let us know if you continue facing issues.
Thanks,
Rohan
from aws-mobile-appsync-sdk-ios.
Hey @rohandubal
Thank you so much for being active and getting back to us let me update my code from swift 4.0 to 4.2 then i'll update to version 2.7.0.
Thanks
from aws-mobile-appsync-sdk-ios.
Hey @rohandubal , Glad to inform problem solved. I have tested too.
from aws-mobile-appsync-sdk-ios.
@DreamBegin, excellent - thank you for the quick verification.
from aws-mobile-appsync-sdk-ios.
@muellerfr @rohandubal - I seem to be seeing this same issue again as dreamBegin was. According to the Podfile manifest is using AWSCore 2.7.4
print("sending")
self.appSyncClient?.fetch(query: getCategoriesQuery, cachePolicy: .fetchIgnoringCacheData) { (result, error) in
print("receiving") <--- !!! THIS line is never printed... !!!
if let error = error as? AWSAppSyncClientError {
print("Error getting Categories from AppSync API: \(error.localizedDescription )")
}
}
If I'm online everything seems to work. If I start the app up offline; I see console logs about http failures with code -1009; but the callback response/error function never gets called at all.
2019-01-31 18:25:48.647836-0600 demo[73287:1155815] TIC TCP Conn Failed [2:0x600002515380]: 1:50 Err(50)
2019-01-31 18:25:48.649090-0600 demo[73287:1155815] Task <2C5F28D4-559A-4408-ACD3-541192729190>.<2> HTTP load failed (error code: -1009 [1:50])
2019-01-31 18:25:48.650034-0600 demo[73287:1155815] Task <6F10656E-D80F-4E98-8F20-89695D100A3C>.<1> finished with error - code: -1009
2019-01-31 18:25:48.656511-0600 demo[73287:1155815] Task <2C5F28D4-559A-4408-ACD3-541192729190>.<2> finished with error - code: -1009
The only difference I see is I'm getting a -1009 not -1001 that DreamBegin was seeing.
from aws-mobile-appsync-sdk-ios.
It sounds like you may be operating on a slightly older version of the SDK. Can you verify that you still have the problem if you upgrade to the latest version of AppSync and all of its dependencies? If you're still having a problem, please open a new issue, so we can avoid conversations on an old thread.
from aws-mobile-appsync-sdk-ios.
@palpatim - Tim, isn't AWSCore 2.7.4 the latest?
from aws-mobile-appsync-sdk-ios.
@NathanaelA 2.8.4 https://github.com/aws-amplify/aws-sdk-ios/releases
from aws-mobile-appsync-sdk-ios.
As @guiracine points out, the latest core is 2.8.4. However, I don't recommend updating minor versions of the dependencies independently of updating AppSync itself. The latest AppSync release (2.9.2) relies on the 2.8.x versions of AWSCore and other dependencies.
from aws-mobile-appsync-sdk-ios.
@palpatim - Youch, your are right, I am quite out of date -- I somehow pinned the AppSync to a 2.6 version that I for some reason I thought was the latest version.
Sorry about that, I feel really stupid right now. false report; 2.9.2 and the core 2.8.4 DID call back properly with an error! So I am good now. Thanks!
from aws-mobile-appsync-sdk-ios.
@palpatim I think this is still an issue, but for other reasons. I'm encountering the same behavior when the user pool token is expired. I've just opened another issue about it here: #185
from aws-mobile-appsync-sdk-ios.
@palpatim - It appears this one is having another issue, I just moved to v2.10.1 to fix other offline issues and this now seems to have an issues again.
My Simple todo Code:
(ids
, name
and desc
are all set before calling this function).
self.appSyncClient!.perform(mutation: CreateTodoMutation(input: CreateTodoInput(id: ids, name: name, description: desc)),
// Record Caching
optimisticUpdate: {
transaction in
do {
try transaction?.update(query: ListTodosQuery()) { (data: inout ListTodosQuery.Data) in
let localItem = ListTodosQuery.Data.ListTodo.Item.init(id: ids,
name: name,
description: desc);
data.listTodos?.items?.append(localItem);
NSLog("Here in optimistic"); // <-- Prints
}
NSLog("Done Optimistic Update"); // <-- Prints
} catch {
NSLog("Error"); // <-- Does NOT print (so we are good!)
}
}) {
(result, error) in
NSLog("Results"); // <-- This never prints.
self._callback(callbackId: callbackID, error: error, results: ids);
};
I dropped breakpoints into the code on the locations that aren't printing and they never get hit, in case the NSLog was being eaten somehow.
The optimistic path is ran if online and offline. (Good)
.Fetch
seems to work offline (and throws an error quickly, Good!)
The final results path on Sending Delete, Update or Create mutation into the .perform
routine do not seem to be called while offline.
from aws-mobile-appsync-sdk-ios.
At the risk of continuing too much conversation on a closed thread:
I wouldn't expect your result handler to be invoked while you're offline--that block only gets called when the mutation is processed by the server during the same app session where the mutation is queued. That is, if the app quits and restarts, that particular callback is lost, and the AppSync client's offlineMutationDelegate
is called instead.
What behavior are you expecting in an offline situation? What about when the system resumes a network connection?
from aws-mobile-appsync-sdk-ios.
@palpatim - Tim,
I'll open other bugs if you prefer that. I just thought this went with #91. 😀
Maybe I'm misunderstanding -- Shouldn't the result handler be called with the error that it is offline? When I send the .perform
I have no idea if the app is online or offline.
-
The optimistic block is called in both (online and offline) cases so that the local data is hopefully cached properly. (might be broken, see below)
-
The Result block seems to only be called if online.
-
I would really like to know that it failed to send the update and is offline. So I believe the correct behavior should be that result callback should be still called with the offline error as it is still an error...
-
Going back online after it appears to have failed (i.e. wait a couple minutes offline); does not seem to call this "lost" handler (so the callback seems to be lost totally in all cases except immediate handling). So if this is supposed to be called on a offline cached record when going back online, that seems to be broken.
-
I was unaware of the
offlineMutationDelegate
; I'll see if I can find the docs on that and see if that can at least track that we are back online and changes have occured... -
The later fetches do not seem to be returning the record even thought the optimistic cache appeared to have worked. (Might be a separate bug). So, I'm not really sure if this whole offline caching system is even working
-- Cached Fetches (i.e. fetch while online) are re-fetched properly while offline
-- Cached and/or offline Adds/Updates/Delete do not seem to be fetched while offline. (so doesn't appear to be cached in sqlite).
from aws-mobile-appsync-sdk-ios.
Maybe I'm misunderstanding -- Shouldn't the result handler be called with the error that it is offline? When I send the
.perform
I have no idea if the app is online or offline.
The current behavior is by design--the idea is that callers should not have to worry about offline vs. online states to perform a mutation. The AppSync client adds every mutation to a queue for serial processing (that ensures mutations are always sent to the server in order). The queue suspends operations when the network drops, and resumes when the network is restored. From a caller's perspective, there is no difference in callback behavior from perform
ing a mutation while network is offline vs. perform
ing a mutation that is at the end of a long queue of mutations.
The optimistic block is called in both (online and offline) cases so that the local data is hopefully cached properly.
Correct! The optimistic update block is there to help developers provide a responsive UI, even if it's doing something like updating a local record in some kind of "pending" state, and letting the app user continue their work. Obviously, that's not appropriate for every operation (e.g., it may be appropriate to optimistically update the UI for a CreateComment operation; whereas it would be inappropriate for a CreateUser operation). Once the mutation result is received from the server, the mutation resultHandler block can reconcile the optimistically updated cache with the actual results from the server (e.g., by removing the optimistic record and add the server record). However, see below for a gap in offlineMutationDelegate
functionality.
The Result block seems to only be called if online.
To refine this--it is called when the result of the mutation is received from the server, during the same appSyncClient lifespan as when the mutation was queued. Obviously restarting the app would cause the result handler block to be lost. Less obviously, destroying and recreating the AppSyncClient would also cause that to happen. (That's a low-frequency use case, but it's possible that an app might be destroy a client in response to authentication events like "sign out".)
I would really like to know that it failed to send the update and is offline. So I believe the correct behavior should be that result callback should be still called with the offline error as it is still an error...
This would make sense to move to a feature request so we can dive into it in more detail. My first impression is that it's not something we'd want to offer, but let's dive into your use case--there was another recent customer request for similar behavior.
Going back online after it appears to have failed (i.e. wait a couple minutes offline); does not seem to call this "lost" handler (so the callback seems to be lost totally in all cases except immediate handling). So if this is supposed to be called on a offline cached record when going back online, that seems to be broken.
Could you file a bug for this (with repro steps if you're able)? I don't confirm that behavior locally, but I may be missing some steps that you are aware of.
I was unaware of the
offlineMutationDelegate
; I'll see if I can find the docs on that and see if that can at least track that we are back online and changes have occured...
There is a known gap in functionality--perform
ing a mutation creates a queue entry with an identifier that is currently not returned to the caller. That means that reconciling offline mutations that don't have shared key data between the optimistic udpate and the result are impossible.
For example, in the common case of a "create" mutation:
appSyncClient.perform()
theCreateObject
mutation offline, or behind a series of other mutations- AppSync writes the mutation payload to a persistent store
- AppSync adds the mutation (and its result handler callback) to an in-memory operation queue
- AppSync invokes the optimisticUpdate block, which updates the cache with some temporary ID
perform()
returns a bareCancellable
with no other identifying information- Quit and resume the app
- AppSync reads the stored mutation payloads. Because they have no associated result handler, they will notify the
offlineMutationDelegate
when they are performed - The mutation is performed on the service, which returns the permanent ID
- AppSync notifies the
offlineMutationDelegate
with the results of the mutation - The
offlineMutationDelegate
updates the localListObject
query cache results - The
offlineMutationDelegate
would like to remove the optimistically updated ID, but there is no way to tie the permanent ID to the temporary ID
There's an open feature request to address this gap. Please feel free to upvote and/or comment on it!
The later fetches do not seem to be returning the record even thought the optimistic cache appeared to have worked.
As I (hopefully) clarified, optimistic updates and the result block are invoked independently of each other, and represent different stages of a mutation lifecycle.
Cached and/or offline Adds/Updates/Delete do not seem to be fetched while offline. (so doesn't appear to be cached in sqlite).
This is a tricky one, because of the way GraphQL and the Apollo cache works. Could you open a new issue for this (again with repro steps if you're able) so we can dive into it further? I have an idea what may be causing this behavior, but I'd like to have a more targeted conversation around it.
from aws-mobile-appsync-sdk-ios.
Related Issues (20)
- Memory leak in AppSyncRealtimeClient HOT 2
- AWSNetworkTransport Error when initializing AWSAppSync in AppDelegateFile SwiftUI - Xcode 13.1 HOT 4
- Add support for Custom Domain Names for AWS AppSync APIs HOT 8
- AWS AppSync SDK with AppSync APIs v2 protocol (pure WebSockets) HOT 1
- AWSAppSyncClient: AWSPerformMutationQueue Crash HOT 2
- Crash: AWSAppSyncClient.sync HOT 5
- Removing pods from source control HOT 2
- AWSMobileClient Crash when app starts HOT 3
- Completion Handler on AWSAppSyncClient.perform called more than once. HOT 1
- Enabling retry for custom scenarios HOT 1
- Update SQLite dependency to match Amplify.DataStore's SQLite version
- Make public constructor for GraphQLError HOT 2
- SPM dependency conflict with Amplify library HOT 6
- Using AWSAppSync with Amplify DataStore HOT 5
- App crashes: AWSAppSync $s10AWSAppSync36AWSCognitoUserPoolsAuthProviderAsyncPAAE09getLatestF5TokenSSyF HOT 1
- SPM dependency resolution failure using aws-mobile-appsync-sdk-ios 3.6.2 and amplify-swift 2.6.0 HOT 2
- AWS subscriptions - subscribe function is not thread safe and causes crashes HOT 1
- Version incompability with other amplify packages HOT 2
- Unknow TCP connection process keep running even when all subscriptions are unsubscribed HOT 1
- How to avoid duplicate mutations when the app is backgrounded/quit before the mutation is finished? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aws-mobile-appsync-sdk-ios.