search

qzind / tray

Browser plugin for sending documents and raw commands to a printer or attached device.
https://qz.io
Other
823 stars 266 forks source link

Connection Abruptly Closes for openStream API Method #1265

Closed krahulrd closed 3 weeks ago

krahulrd commented 1 month ago

Hello Team,

We are integrating QZTray with a weight scale on our website. Currently, we are utilizing the openStream() method from hid to fetch the stream of weight data. As per our application requirements, we need to open and close this connection multiple times. However, when we open a new connection, it sometimes emits the close event with code 1006 and throws the error:

Error: Connection closed before response received

Screenshot 2024-05-14 at 12 13 38 AM

As customers, we do not have control over this close event. We would like to understand why the connection is closing abruptly only when using the openStream() method.

Note: The same connection works fine for the readData() method.

Thank you.

tresf commented 1 month ago

@krahulrd code 1006 is abnormal and usually the sign of a bug.

What we'd expect as a bare minimum:

What might be insightful:

If it can, great. If it cannot, it will be harder to track down.

Lastly, if the crash occurs with a Premium Support account, we can start an email exchange with the client and offer a screenshare.

krahulrd commented 1 month ago

@tresf Thanks for the quick turnaround!

Yes, this issue is reproducible here: https://demo.qz.io/#hidContent

Steps to reproduce in the above URL:

  1. Click on the QZ Tray Connect button > List Devices > Use This > Claim Device > Open Stream.
  2. Reload the page. The Open Stream output is lost, but the QZ Tray connection remains active.
  3. Repeat the same process to connect to Open Stream: List Devices > Use Device > Claim Device > Open Stream. Right after the first click of List Devices, QZ Tray crashes and I see the below error:

(index):2988 Error: Connection closed before response received at _qz.websocket.connection.onclose (qz-tray.js:203:72)

After a few seconds, QZ Tray is coming back.

Our application also faces the same issue whenever a user reloads or closes the browser tab and then tries to connect again. As a backup, we have implemented retry mechanisms, but sometimes this is problematic. If QZ Tray completely crashes, the retry mechanism won't work.

Please let me know if any further information is needed.

Our QZ Tray version is 2.2.2 on a Mac device, but this issue occurs regardless of the OS and QZ Tray version.

tresf commented 1 month ago

Our QZ Tray version is 2.2.2 on a Mac device, but this issue occurs regardless of the OS and QZ Tray version.

Hmm... if it's a HARD crash, I would expect the symptoms to vary between OSs, since they use different libraries.

For Mac, we use one called hid4java, but for Windows, we use one called purejavahidapi.

If it's a SOFT crash, I would expect it to be rather consistent. I remember in the past we had some listeners to cleanup, maybe we missed one. I'll take a look.

tresf commented 1 month ago

Just a status update, we're still actively investigating the crash on the MacOS side. We'll provide an update here once we're able to narrow it down.

tresf commented 4 weeks ago

Turns out macOS was a resurfacing of #137, a regression caused by #1177. We should have that patched soon.

This also means that you may revert to QZ Tray 2.2.2 and it should prevent the macOS HID crashes while you await the patch to land (e.g. QZ Tray 2.2.4).

tresf commented 4 weeks ago

Upstream patch:

Downstream patch:

Ready for testing here:

krahulrd commented 3 weeks ago

Wow! Thanks for the update and great turnaround.

tresf commented 3 weeks ago

Wow! Thanks for the update and great turnaround.

Did it fix it for you? We haven't merged #1267 yet.