Current Behavior
When trying to send a Websocket message to a local client using the standard Aws.ApiGatewayManagementApi connector in serverless-offline, the connector's TCP connection to the client is refused. However this works fine when deployed to AWS.
Tested on MacOS Catalina 10.15.3.
See https://github.com/bryanvaz/sls-websocket-demo for demo of the issue.
Not sure if this is a weird MacOS firewall issue or something else someone has encountered before. I can't seem to figure out why the initial connection is successful, but sending messages fails.
Detailed Error Message
Unable to generate socket message Error: connect ECONNREFUSED 127.0.0.1:443
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1137:16) {
message: 'connect ECONNREFUSED 127.0.0.1:443',
errno: 'ECONNREFUSED',
code: 'NetworkingError',
syscall: 'connect',
address: '127.0.0.1',
port: 443,
region: 'us-east-1',
hostname: '',
retryable: true,
time: 2020-03-17T16:37:57.040Z
}
->StackTrace:
Error: connect ECONNREFUSED 127.0.0.1:443
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1137:16)
Sample Code
See https://github.com/bryanvaz/sls-websocket-demo for simple demo and full description of the issue.
Expected behavior/code
The serverless-server should respond with a {"action":"PING", "value":"PONG"} message to the client.
Environment
serverless version: v1.66.0serverless-offline version: v5.12.1 (also happens with v6.0.0-alpha.68)node.js version: v12.16.1OS: macOS 10.15.3I am having same issue.
I was able to fix the issue, not sure it is with serverless but in your code https://github.com/bryanvaz/sls-websocket-demo/blob/b1c614c4db1adfedff92d399d2a6fedf407d366a/src/connector/apigateway.connector.js#L9
if you point endpoint to http://localhost:3001 which is default serverless than it should work
Bare in mind your config might be correct in aws, you only need to do that in local development
Thanks @jimishshah, but the point of the WS endpoint for serverless-offline is to test the function with a corresponding WS client that connects over WS.
@dnalborczyk I noticed you've been patching most of the WS server code in Dec. Did you ever get the WS server to send messages to the client locally?
That functionality is critical for CI-based integration and behaviour tests (Realized this is actually the most important use case last week when I spent 3 hrs digging through lamda logs.)
@bryanvaz You said it well but still figured i'd share my current work around when using websockets locally with sls offline that is working well for now.
const gatewayApi = new ApiGatewayManagementApi({
apiVersion: '2018-11-29',
// `sls offline` has [issue](https://github.com/dherault/serverless-offline/issues/924) where it can't send
// the message back to the websocket client (using ws://localhost:3001).
// TODO: look for a fix to this hack
endpoint: process.env.IS_LOCAL_SERVERLESS_MODE ? `http://localhost:3001` : `${event.requestContext.domainName}/${event.requestContext.stage}`,
});
Here is a web client correctly receiving the message back.

@ChrisTowles Nice now I get it (@jimishshah now I get what you were trying to say)
Honestly I think that might be the correct way to wire up the backend. The integration tests for the websocket functionality that is sitting on a PR(GH-814) are set up the exact same way
I used a slightly different proces.env.IS_OFFLINE
const endpoint = process.env.IS_OFFLINE ? 'http://localhost:3001' : ${domainName}/${stage};
Most helpful comment
@bryanvaz You said it well but still figured i'd share my current work around when using websockets locally with
sls offlinethat is working well for now.Here is a web client correctly receiving the message back.
