-
Notifications
You must be signed in to change notification settings - Fork 138
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
Update python-socketio & python-engineio to latest #2591
Comments
Linking to stepping stone issue #2625 |
Just playing with dependencies here:
That gets us to 2.1.1... maybe due to |
We have a requirement to update python-engineio upon which python-socketio depends: however we have the following:
So we may be able to independantly update the engineio part. python-engineio
Version run-down:Notable changes: Release 4.7.1 - 2023-09-12
Release 4.7.0 - 2023-09-03
Release 4.6.0 - 2023-08-21
Release 4.5.0 - 2023-07-05
Release 4.4.0 - 2023-03-16
... Release 4.3.2 - 2022-04-24
... Release 4.2.0 - 2021-05-15
...
From the above we can now likely unpin python-engineio entirely. |
If we remove our python-engineio pinning we get:
Viewing our Dashboard post this one change and we have 404 on all socket request: No header 'live' info and no widget info. Response for each (Web-UI network tools: "Response" tab on detail of failed call: Response Payload: "The client is using an unsupported version of the Socket.IO or Engine.IO protocols" |
Downgrading to say 3.14.2 and we get:
But see a different failure re: So we have quite a few changes along the way here. 3.13.2 gives bad request !! And likewise with our minimal fix of 3.9.0.
|
just found a seemingly "working combination": python-engineio==3.13.2 |
python-socketio
Last rockstor-core changes: Issue#1503 migrating gevent socketio to python socketio #1510 |
@Hooverdan96 Re: • Updating python-engineio (3.9.0 -> 3.13.2) For me is still a bad request. Have your disabled network cache in Browser and reloaded dashboard. Bit of a pain all this as we are to throw out for Django Channels 4 so don't really want to mess with it too much. But we have to update our python-engineio. Hence dabbling rather than looking at it properly. |
I know, this is in the context of Flask, but this might be useful too in the Django context: https://flask-socketio.readthedocs.io/en/latest/intro.html#version-compatibility And I would be remiss for not giving credit to this thread: |
And yes, cleaning out all the caches on the browser made the above suggestion fail for me, too ... |
Yes that's valid, @Hooverdan96 , it's the compatibility table from python-socketio directly: |
@Hooverdan96 Yes I saw this table. And was tempted to just up our entire stack end-to-end. Hence re-referencing the jslibs changes back-then. As I suspect we will run into protocol issues otherwise. And they seem to have thrown in some more orgin tests etc. Not motivated to re-write with Channels on this testing run so will likely just read-up more on what's going on here. So maybe we just up everything end-to-end. But we don't have automated testing for jslibs modifications so a bit more tedious. I'll have a think and re-visit I think. Our versions are super old so maybe we just up everything and fix what's broken then. |
Going all-in on newest available here will bring the following benefit: https://github.com/miguelgrinberg/python-engineio/blob/main/CHANGES.md#python-engineio-change-log
|
With the latest debug version of our js client library (socket.io.js) in place, and the latest of both python-socketio and python-engineio installed we get, via Web dev tools in browser: "Not an accepted origin." as Response. Potential pointers: https://socket.io/docs/v4/handling-cors/ |
To review our server implementation we have: Installation: https://python-socketio.readthedocs.io/en/latest/server.html Deployment strategies: https://python-socketio.readthedocs.io/en/latest/server.html#deployment-strategies N.B. our current deployment is via gevent : It is proposed that we make the minimum changes to re-enable functionality for the time being. |
We have the initial call responding as expected: Python-socketio troubleshooting: https://python-socketio.readthedocs.io/en/latest/server.html#debugging-and-troubleshooting
but follow-ups all get "Not an accepted origin." as the response. Useful info when right-clicking on the many 400 (BAD REQUEST) in browser dev tools and selecting:
|
When looking at this issue: though Rockstor is not using
compared to what is in Rockstor's nginx.conf:
I don't want to slow you down, if that's helpful, great, if not, just carry on, you will figure it out :) |
@Hooverdan96 Thanks, I'll take a look on my next session. I had wonered about the proxy but not taken a look yet.
do look interesting, given the tighter controls on these that look to have been introduced in the newer versions of the client and server of socketio. All quite frustrating but getting there I think. However I did experiment with some server options that should have allowed any client access and still got the refusals. |
Before proxy changes:
Post suggested changes and we still have the same behaviour:
However we do have some communication here, and the initial response from the server giving the 'sid' is in response to a protocol 4 (?EIO=4) request. So we are stuck on establishing the websocket I think: I.e. the initial GET works as intended to initiate a protocol switch to websocket and gets status 101 POST request: > https://lbuildvm.lan/socket.io/?EIO=4&transport=polling&t=OijquzC&sid=ckj3sQjF9IWGCjB2AAA7 We also get successful polling events by the look of it. So the key here is: I'll review our dependencies on the browser side here as this looks like we may be missing something that has emerged in the last 7 years !! |
Is already in play when the dev setup initiates our Python-serverio in data_collector.py.
|
OK, here-it-comes:
Works much better !!!! I'll pretend this didn't happen and stagger on with what is now a tone of stuff working again :). |
Raise pinned versions to latest available: ## Includes: - Revised nginx reverse proxy for data_collector app. - Replace gevent-websocket with simple-websocket. - Replace gevent for regular Python threads in socketio.Server.
Raise pinned versions to latest available: ## Includes: - Revised nginx reverse proxy for data_collector app. - Replace gevent-websocket with simple-websocket. - Replace gevent for regular Python threads in socketio.Server.
…-python-engineio-to-latest Update python-socketio & python-engineio to latest #2591
Closing as: |
Post #2567 in testing branch we are no longer limited by Py2.7. It is proposed that we update this primary dependency accodingly. From https://pypi.org/project/python-socketio/ we have the latest version still supporting our now prior Py3.6 base. [EDIT: we now use Py3.9 as of #2692],
N.B. we use a js library as our client so we must co-ordinate an update accordingly in our https://github.com/rockstor/rockstor-jslibs repository.
Linking to the last update of this client js library for context:
#1503
Note also the interdependency within our Python dependency on
Also noting the larger context of replacement of this mechanism with the Django build-in channels 4.0:
https://github.com/django/channels/
https://channels.readthedocs.io/en/latest/releases/4.0.0.html
Which in turn requires at least Py3.7 [EDIT: we use Py3.9 now] and our next planned Django LTS version of 3.2, see Milestone: https://github.com/rockstor/rockstor-core/milestone/24
As the original Channels (Channels 1) underwent a major breaking change re-write in Channels 2:
https://channels.readthedocs.io/en/latest/releases/2.0.0.html
we want to avoid Channels 1 (which is compatible with our current Django) entirely.
The text was updated successfully, but these errors were encountered: