Connectivity issues and "bad file descriptor" errors

[damir-fell]

Description

Hello,

In our app we are experiencing the issue described in this dart issue thread: dart-lang/http#197. Going through our code it seems that we are doing everything right in terms of stopping subscriptions and similar when app goes to background but for some reason it doesnt look like the connection pool is cleared.

We want to try to replace the http client Amplify is using with http_cupertino on ios as suggested by that thread. How can we do this? Do we need to do something within the amplify libraries itself or how is the http package provided?

Categories

• Analytics
• API (REST)
• API (GraphQL)
• Auth
• Authenticator
• DataStore
• Notifications (Push)
• Storage

Steps to Reproduce

It is usually reproduced when app goes to foreground after being in background for extended period of time. What happens is that all queries start to fail and any retries or similar later does not recover the issue. The app has to be restarted in order to recover.

Screenshots

No response

Platforms

• iOS
• Android
• Web
• macOS
• Windows
• Linux

Flutter Version

3.13.8

Amplify Flutter Version

1.7.0

Deployment Method

AWS CDK

Schema

No response

[damir-fell]

Its related to this issue: #3865

and we are using suggested comment here to address the issue: #3865 (comment)

[ekjotmultani]

Hello @damir-fell, I'm sorry you are experiencing these issues. Can you please try updating to the latest release 2.5.0 of amplify-flutter and report back if it solved the issue?

[damir-fell]

Hi @ekjotmultani
We can, however I have a couple of questions related to it:

1. Can we use normal Amplify.API requests on the new major version? The V2 docs differs to the V1 and there is no explanation on how to configure setup with an existing AWS Appsync api and use the API plainly and not through Data.
2. Do you expect this to help? Has there been improvements/changes in the library that you think can fix the issue?

It will take some time due to the breaking changes and I would like to resolve the issue as quickly as possible

[tyllark]

Hello @damir-fell

1. Yes you can continue using normal Amplify.API requests I was able to run the following on both v1.8.0 and v2.5.0

final todo = Todo(
  id: uuid(),
  name: '',
);

try {
  final request = ModelMutations.create(todo);
  await Amplify.API.mutate(request: request).response;
} catch (e, st) {
  Logger.log('Create Exception', '$e - $st');
}

You can migrate from "Gen 1 v1" to "Gen 1 v2" using this guide.

2. v2.5.0 includes a few bug fixes to our WebSockets such as how they handle resuming from a paused state. If you can provide me a code snippet for what's causing your issue I can try to reproduce the issue in v1.8.0 and check if it's working in v2.5.0.

[damir-fell]

Thanks for the response, we will update the library and Flutter version and see.

About reproduction, its not really a code snippet or something I can share. Basically our app uses a bunch of subscriptions, queries and mutations and we seem to get problems when app has been in background for a long time and when put to foreground we get many "failed to lookup host" and "bad file descriptor" issues. It funnily enough doesn't look like subscriptions are the issues, but rather queries and mutations.

Here are a couple of examples

Error: UnknownException {
  "message": "unable to send GraphQLRequest to client.",
  "underlyingException": "POST https://.../graphql failed: HttpException: Bad file descriptor, uri = https://.../graphql"
},

 UnknownException {
  "message": "unable to send GraphQLRequest to client.",
  "underlyingException": "POST https://.../graphql failed: SocketException: Failed host lookup: '...' (OS Error: nodename nor servname provided, or not known, errno = 8)"

It is not internet issues as this happens with multiple users on random timestamps, and its occurring as long as app is alive. If app is killed and opened again the issues are gone.

We stop subscriptions when app is put to background and restore it when app is put to foreground but the issues keep reappearing either way as long as the app session is active.