Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

failed: Close received after close #448

Open
chjiyun opened this issue May 3, 2024 · 7 comments · May be fixed by #476
Open

failed: Close received after close #448

chjiyun opened this issue May 3, 2024 · 7 comments · May be fixed by #476

Comments

@chjiyun
Copy link

chjiyun commented May 3, 2024

Hello, I recently encountered a problem. Can someone help me take a look?,
I used the example and successfully ran it, but I sent a ping to the server and received an error below:

WebSocket connection to 'ws://127.0.0.1:8888/subscribe' failed: Close received after close
@nhooyr
Copy link
Contributor

nhooyr commented May 4, 2024

Can you show your client code?

@chjiyun
Copy link
Author

chjiyun commented May 7, 2024

@nhooyr go version 1.22.2

conn.addEventListener('open', ev => {
    console.info('websocket connected')
    setTimeout(() => {
      conn.send('ping')
    }, 3000)
  })

@nhooyr
Copy link
Contributor

nhooyr commented May 7, 2024

Unrelated to the library. Something's wrong with your client code calling close after the connection has been closed. See mqttjs/MQTT.js#1361

@nhooyr nhooyr closed this as completed May 7, 2024
@fogrye
Copy link

fogrye commented May 16, 2024

I would reopen this as after last update I have received same error with native WebSocket in Chrome, while safari is ok with that.

@nhooyr nhooyr reopened this May 16, 2024
@nhooyr
Copy link
Contributor

nhooyr commented May 16, 2024

Ok possible we need to add a guard in c.writeClose to not write a close frame twice. I think that we're writing a close frame, we get a close frame back and then the code doesn't keep track that it already wrote a close frame and so writes a close frame in response to the handshake close frame.

@fogrye
Copy link

fogrye commented May 16, 2024

Yes, I saw that it's waiting for closing but CloseNow did not check if it was closed already. I believe that's what's happening.

FrauElster added a commit to FrauElster/websocket that referenced this issue Sep 5, 2024
@mafredri mafredri linked a pull request Sep 5, 2024 that will close this issue
paveloom pushed a commit to flowey-org/websocket that referenced this issue Oct 30, 2024
paveloom added a commit to flowey-org/Flowey that referenced this issue Oct 30, 2024
That fork includes a fix for the extra close frame problem. See:
- coder/websocket#448
- coder/websocket#476
@dgpc
Copy link

dgpc commented Nov 13, 2024

Is #476 the chosen approach here, and if so anything we can do to get it merged? My application is experiencing this same issue.

I also noticed another project had decided to fork the library in order to pick up this solution: flowey-org@b1784e6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants