API.cancel doesn't work

Before opening, please confirm:

• I have searched for duplicate or closed issues and discussions.
• I have read the guide for submitting bug reports.
• I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

JavaScript Framework

React Native

Amplify APIs

GraphQL API

Amplify Categories

api

Environment information

System:
    OS: Windows 10 10.0.22000
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
    Memory: 2.16 GB / 15.69 GB
  Binaries:
    Node: 14.18.0 - C:\Program Files\nodejs\node.EXE
    npm: 6.14.15 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.22000.120.0), Chromium (95.0.1020.44)
    Internet Explorer: 11.0.22000.120
  npmPackages:
    @aws-amplify/ui-components: ^1.7.2 => 1.7.7
    @babel/core: ^7.15.0 => 7.15.5
    @babel/plugin-transform-modules-commonjs: ^7.15.0 => 7.15.4
    @babel/preset-env: ^7.15.0 => 7.15.4
    @babel/preset-react: ^7.14.5 => 7.14.5
    @babel/preset-typescript: ^7.15.0 => 7.15.0
    @babel/runtime: ^7.15.3 => 7.15.4
    @react-native-async-storage/async-storage: ^1.15.5 => 1.15.7
    @react-native-community/eslint-config: ^2.0.0 => 2.0.0
    @react-native-community/netinfo: ^6.0.0 => 6.0.2
    @react-native-firebase/app: ^12.4.0 => 12.7.5
    @react-native-firebase/crashlytics: ^12.4.0 => 12.7.5
    @react-native-masked-view/masked-view: ^0.2.6 => 0.2.6
    @react-navigation/drawer: ^6.1.0 => 6.1.4
    @react-navigation/native: ^6.0.2 => 6.0.2
    @react-navigation/native-stack: ^6.1.0 => 6.1.0
    @react-navigation/stack: ^6.0.3 => 6.0.7
    @reduxjs/toolkit: ^1.6.1 => 1.6.1
    @reduxjs/toolkit-query:  1.0.0
    @reduxjs/toolkit-query-react:  1.0.0
    @testing-library/jest-native: ^4.0.2 => 4.0.2
    @testing-library/react-native: ^7.2.0 => 7.2.0
    @types/jest: ^26.0.14 => 26.0.24
    @types/react: ^17.0.19 => 17.0.20
    @types/react-native: ^0.64.13 => 0.64.15 (0.65.0)
    @types/react-native-honeywell-scanner: ^1.0.0 => 1.0.0
    @types/react-test-renderer: ^17.0.1 => 17.0.1
    @typescript-eslint/eslint-plugin: ^4.29.3 => 4.31.0 (3.10.1)
    @typescript-eslint/parser: ^4.29.3 => 4.31.0 (3.10.1)
    HelloWorld:  0.0.1
    amazon-cognito-identity-js: ^5.0.6 => 5.1.0
    amplify-ui-components-loader:  undefined ()
    aws-amplify: ^4.2.2 => 4.2.8
    babel-jest: ^26.3.0 => 26.6.3
    eslint: ^7.32.0 => 7.32.0
    hermes-inspector-msggen:  1.0.0
    husky: ^7.0.0 => 7.0.2
    i18next: ^20.4.0 => 20.6.1
    jest: ^26.4.2 => 26.6.3
    metro-react-native-babel-preset: ^0.64.0 => 0.64.0
    native-base: ^3.0.7 => 3.1.0
    react: 17.0.1 => 17.0.1
    react-hook-form: ^7.15.2 => 7.15.2
    react-i18next: ^11.11.4 => 11.11.4
    react-native: 0.64.1 => 0.64.1
    react-native-code-push: ^7.0.1 => 7.0.1
    react-native-config: ^1.4.3 => 1.4.4
    react-native-elements: ^3.4.2 => 3.4.2
    react-native-exception-handler: ^2.10.10 => 2.10.10
    react-native-fs: ^2.18.0 => 2.18.0
    react-native-gesture-handler: ^1.10.3 => 1.10.3
    react-native-honeywell-scanner: ^2.0.0 => 2.0.0
    react-native-image-picker: ^4.0.6 => 4.0.6
    react-native-reanimated: ^2.2.0 => 2.2.0
    styled-components/native:  undefined ()
    styled-components/primitives:  undefined ()
    styled-system: ^5.1.5 => 5.1.5
    ts-jest: ^26.4.1 => 26.5.6
    typescript: ^3.9.10 => 3.9.10
  npmGlobalPackages:
    react-native-cli: 2.0.1

Describe the bug

We are trying to standardize an app behavior under poor connection scenarios, what we’d like to achieve is to cancel pending GraphQL requests if these don’t fulfill under a given timeframe.

For that purpose we’ve already implemented the time related logic, but when we try to cancel the pending requests with the API.cancel as described in https://docs.amplify.aws/lib/graphqlapi/cancel-request/q/platform/js/ it does nothing

We have also tried to get help in the discord channels but without any response, other ppl seem to have incurred into the same issue

We’ve taken care of using the original promise (not a wrapped one) to cancel the request as the documentation warns

Expected behavior

We expect that when calling API.cancel the request is immediately cancelled

Reproduction steps

To easily explain what we are expecting to happen, a ‘simple example’ is provided as a code snippet, in this example, and based on what we see in the documentation, we expect an error to be thrown, but instead the request is completed normally

Code Snippet

// Put your code below this line.
console.log(new Date().toISOString(), 'before api.graphql')

const promise = API.graphql({
  query: ...,
  variables: ...
})

console.log(new Date().toISOString(), 'before api cancel')

API.cancel(promise, 'test')

console.log(new Date().toISOString(), 'after api cancel')

const result = (await promise)

console.log(new Date().toISOString(), 'result: ', result)

...
} catch (error: unknown) {
  console.log(new Date().toISOString(), 'an error occurred: ', error)
  ...
}

Log output

// Put your logs below this line
 LOG  2021-11-11T17:58:22.179Z before api.graphql
 LOG  2021-11-11T17:58:22.188Z before api cancel
 LOG  2021-11-11T17:58:22.189Z after api cancel
 LOG  2021-11-11T17:58:24.337Z result:  {...}

 LOG  2021-11-11T17:58:41.833Z before api.graphql
 LOG  2021-11-11T17:58:41.835Z before api cancel
 LOG  2021-11-11T17:58:41.837Z after api cancel
 LOG  2021-11-11T17:58:42.735Z result:  {...}

 LOG  2021-11-11T17:58:54.768Z before api.graphql
 LOG  2021-11-11T17:58:54.771Z before api cancel
 LOG  2021-11-11T17:58:54.773Z after api cancel
 LOG  2021-11-11T17:58:55.652Z result:  {...}

aws-exports.js

No response

Manual configuration

No response

Additional configuration

No response

Mobile Device

No response

Mobile Operating System

No response

Mobile Browser

No response

Mobile Browser Version

No response

Additional information and screenshots

No response

[david-mcafee]

Hi @gweisz-440it - perhaps you haven’t included it in your sample, but have you tried if(API.isCancel(error)) in your try / catch block, as outlined in the docs?

[jowo-io]

@jamesaucode ahh, i see! that’s brilliant though thanks for opening the PR on this issue.