Connection Abruptly Closes for openStream API Method

[krahulrd]

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

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]

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

• This bug may be our own code or code that we leverage from an HID project.
• To reproduce locally, we'd love to know more about how you can trigger this bug.
• If it's not too much to ask, I'd love to know if this can be reproduced using https://demo.qz.io/#hidContent

What we'd expect as a bare minimum:

• OS
• QZ Tray version
• If it can be reproduced on another machine

What might be insightful:

• Close QZ Tray
• Launch QZ Tray from console and see if there's anything usable that happens with the crash occurs: https://qz.io/docs/faq#console-logs

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]

@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]

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]

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]

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]

Upstream patch:

• MacOS Thread Related Crash Fix gary-rowe/hid4java#153

Downstream patch:

• macOS: Fix HID crashing regression #1267

Ready for testing here:

• https://github.com/tresf/tray/releases/download/v2.2.4/qz-tray-2.2.3+35-arm64.pkg

[krahulrd]

Wow! Thanks for the update and great turnaround.

[tresf]

Wow! Thanks for the update and great turnaround.

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