aws-amplify / amplify-category-api

The AWS Amplify CLI is a toolchain for simplifying serverless web and mobile development. This plugin provides functionality for the API category, allowing for the creation and management of GraphQL and REST based backends for your amplify project.
https://docs.amplify.aws/
Apache License 2.0
89 stars 76 forks source link

amplify mock api not working with subscriptions #2221

Open pieter-vandenburg opened 8 months ago

pieter-vandenburg commented 8 months ago

How did you install the Amplify CLI?

npm install -g @aws-amplify/cli

If applicable, what version of Node.js are you using?

v21.5.0

Amplify CLI Version

12.10.1

What operating system are you using?

Arch Linux

Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.

No

Describe the bug

When using mock for the backend

$ amplify mock api

With the following subscription:

useEffect(() => {
  const subscription = client
    .graphql({ query: subscriptions.onCreateTodo })
    .subscribe({
      next: ({ data }) => console.log(data),
      error: (error) => console.warn(error)
    });
  return () => subscription.unsubscribe();
}, []);

And the following schema:

type Todo @model {
  id: ID!
  name: String!
  description: String
}

fails with error:

index.ts:69 WebSocket connection to 'wss://192.168.1.10:20002/graphql/realtime?header=LONG_CODE_TRUCATED&payload=e30=' failed: 

Expected behavior

Testing api locally with mock should work. I've tried this in other projects with differing schema's but all fail with the same error. Broke this problem down to it's basics for bug report.

Reproduction steps

  1. npx create-react-app test_amplify
  2. cd test_amplify
  3. amplify init
  4. amplify add api (Accepting defaults)
  5. npm install aws-amplify
  6. Write the subscription code above in App.js
  7. amplify mock api
  8. npm run start

Project Identifier

2ebfbe4ebc7ed43fb28d4bdadd09d8be

Log output

``` # Put your logs below this line ```

Additional information

Similiar to issue 555 and 122 but different output and they are resolved with version updates. Also, I'm not sure if the local protocol should be ws:// rather than wss://, but I thought it worth pointing out.

Before submitting, please confirm:

pieter-vandenburg commented 8 months ago

image

pieter-vandenburg commented 7 months ago

Is there any movement on this?

AakashKB commented 7 months ago

I've been emailing them on same issue, seems it is blocked by another PR