Handle the AWSAppSyncClient timeout about aws-mobile-appsync-sdk-ios HOT 19 CLOSED

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.

@NathanaelA

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.

@NathanaelA

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.

@NathanaelA

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 performing a mutation while network is offline vs. performing 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--performing 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() the CreateObject 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 bare Cancellable 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 local ListObject 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.