OctoEverywhere fails to properly connect

[crysxd]

I'm the dev of OctoApp.

I received a couple of reports from users who can't connect OctoApp to octo4a via OctoEverywhere. On the app side, the websocket is abruptly closed in an improper fashion.

The OctoPrint logs show the following whenever the app opens a connection:

2022-09-24 09:34:34,069 - octoprint.plugins.octoeverywhere - ERROR - Web Stream ws   [142]  got an error from the websocket: 'socket' object has no attribute 'pending'
2022-09-24 09:34:35,413 - octoprint.plugins.octoeverywhere - ERROR - Web Stream ws   [150]  got an error from the websocket: 'socket' object has no attribute 'pending'
2022-09-24 09:34:36,791 - octoprint.plugins.octoeverywhere - ERROR - Web Stream ws   [157]  got an error from the websocket: 'socket' object has no attribute 'pending'
2022-09-24 09:34:38,143 - octoprint.plugins.octoeverywhere - ERROR - Web Stream ws   [163]  got an error from the websocket: 'socket' object has no attribute 'pending'
2022-09-24 09:34:38,891 - octoprint.plugins.octoeverywhere - ERROR - Main request failed and we have no more fallbacks. We DON'T have a main response.
2022-09-24 09:34:39,630 - octoprint.plugins.octoeverywhere - ERROR - Web Stream ws   [170]  got an error from the websocket: 'socket' object has no attribute 'pending'
2022-09-24 09:34:39,634 - octoprint.plugins.octoeverywhere - ERROR - Exception in web stream [170] connect loop.; Exception: 'NoneType' object has no attribute 'SendWithOptCode'
2022-09-24 09:34:39,642 - octoprint.plugins.octoeverywhere - ERROR - Session reported an error [wss://[lon.octoeverywhere.com/octoclientws[10]](http://lon.octoeverywhere.com/octoclientws%5B10%5D)], closing the websocket. Backoff time sec: 1

I was able to reproduce the issue with octo4a compiled from eec3a106b3a14e8722df96bc260c0152e83dfc06 and a patch to use OctoPrint 1.8.2 instead of 1.8.3. I'm not quite sure if this issue is on the side of @QuinnDamerell or with octo4a, but to me it looks a bit like a dependency issue.

[QuinnDamerell]

Thanks @crysxd!

I have seen issues like this before, and it's usually due to the WebSocket lib being outdated. Typically I don't enforce a version in the plugin, because OctoPrint demands a very specific version. I tried to update it once, and I broke OctoPrint very hard. lol.

Does anyone know if octo4a does anything different from OctoPrint in terms of the websocket lib used?

[crysxd]

Just to push this a bit, just received another report from an affected user :)

[Smasher350]

I am also having this issue.

[Hollywood25201]

Does anyone have a workaround for the time being?

Thanks!

[QuinnDamerell]

@Hollywood25201 @Smasher350 can you open a supper ticket with me so we can debug it?

https://octoeverywhere.com/support

[crysxd]

@Hollywood25201 I might have something for you as well if your issue is with OctoApp. Drop me a support ticket as well :) [email protected]

[Hollywood25201]

Thanks guys, I'll be sure to do that after I get off work tonight!

[QuinnDamerell]

It seems to be a problem with an update to the websocket-client lib.

https://github.com/websocket-client/websocket-client/issues/857

OctoPrint's deps for websocket-client bind it to: "websocket-client>=1.2.1,<2", https://github.com/OctoPrint/OctoPrint/blob/b38785a25aeef457ee615f2b56e10b6e93c038be/setup.py#L67

So I think all newer installs of OctoPrint might hit this issue. Maybe most OctoPrint instances are safe because OctoPi might not update websocket-client automatically; it might be pinned on a fixed version that's baked into the image? In that case, it would only effect users of OctoPrint who manually install OctoPrint with no existing websocket-client lib on their box.

[QuinnDamerell]

Ah ha, I think I might have a work around!

I just pushed a change to master of my plugin that forces the websocket-client lib to stay under 1.4.0, which I think resolves the issue. I tested it only phone locally and it fixed the issue for me!

So for anyone hitting this (@Hollywood25201, @Smasher350) try uninstalling OctoEverywhere and re-installing it*. That will force the plugin to update since I haven't pushed the update quite yet.

Give that a try and let me know if it works!

[Hollywood25201]

Ah ha, I think I might have a work around!

I just pushed a change to master of my plugin that forces the websocket-client lib to stay under 1.4.0, which I think resolves the issue. I tested it only phone locally and it fixed the issue for me!

So for anyone hitting this (@Hollywood25201, @Smasher350) try uninstalling OctoEverywhere and re-installing it*. That will force the plugin to update since I haven't pushed the update quite yet.

Give that a try and let me know if it works!

I'll try this after my current print!

[Hollywood25201]

Ah ha, I think I might have a work around!

I just pushed a change to master of my plugin that forces the websocket-client lib to stay under 1.4.0, which I think resolves the issue. I tested it only phone locally and it fixed the issue for me!

So for anyone hitting this (@Hollywood25201, @Smasher350) try uninstalling OctoEverywhere and re-installing it*. That will force the plugin to update since I haven't pushed the update quite yet.

Give that a try and let me know if it works!

This worked first try!

I did have to redo my octoapp printer connection, but, after that, it worked wonders!

Thanks @QuinnDamerell and @crysxd for all your help!

[QuinnDamerell]

No problem! I'm glad it worked and thanks for testing for me!

[QuinnDamerell]

I think for now we can close this. The only other thing to do would be to get OctoPrint to also avoid the 1.4.x, but I'm not sure if it's a problem for OctoPrint, since it doesn't use SSL sockets.