Closed gwynforthewyn closed 8 months ago
One of my colleagues just sent me this note:
I just grepped the codebase a bit and it appears to be creating the websocket url from the DEFAULT_SERVER_URL const, rather than from what the server URL is actually determined to be after command line and env var interpolation
We are, of course, not super familiar with this codebase but he's a sharp dude and so I thought I should pass it forwards.
Thanks for the report. I'll have to dig into this a little bit but note that this would be extremely surprising, Panel apps are deployed in many forms on many different ports every day so if there was a regression here it would have definitely been caught by now.
One quick question is why you are even setting the allowable websocket origin when you're just serving on localhost. Is this just you doing testing for an actual deployment?
Skimmed over your question too quickly, sounds like you tried without it and that failed too. Do other ports work? I have no issues with port 8080 but I can imagine that it might be reserved for something on your system.
I really appreciate the response, thank you! tl;dr I came home and can't reproduce it on my personal laptop; I'll see what I can figure out in the morning, but this looks like a bad report, sorry.
Before I had filed this issue, I was experiencing it with a couple of different applications. I asked one of my colleagues at work about it, and he tried upgrading a panel app from 0.13.1 to the latest version; he didn't experience the problem before the upgrade, but as soon as he had upgraded the issue was there for him too.
I'll close this and let's assume that we both had an orphaned container or something that was binding to port 8080; if we can still reproduce it, though, on separate hardware and separate networks tomorrow then I'll try and track down more specifics.
Thanks, once again
Thanks for contacting us! Please read and follow these instructions carefully, then delete this introductory text to keep your issue easy to read. Note that the issue tracker is NOT the place for usage questions and technical assistance; post those at Discourse instead. Issues without the required information below may be closed immediately.
ALL software version info
macos 14.3.1, running on a Macbook Pro with Apple M1 Pro.
requirements.txt:
a pip freeze shows:
Description of expected behavior and the observed behavior
I built a simple panel app with template.Servable(). I initially ran it on the default port 5006, and it ran correctly. Then I tried to override the port to 8080, and the application broke with a websocket timeout error. I expected the changed port to make no difference to whether the app was served or not.
When I ran it with the defaults and it worked, I ran it like this:
panel serve simplepanel.py
I visited http://localhost:5006/ and was correctly served the app.
Then I tried several methods to switch to port 8080. I started with this:
panel serve --port 8080 simplepanel.py
I visited http://localhost:8080 and the app was not served; I received a socket timeout in my web browser.
I also tried these variants:
panel serve --port 8080 --allow-websocket-origin=localhost:8080 simplepanel.py
Note that the above combination of BOKEH_ALLOW_WS_ORIGIN and the 2 CLI parameters worked correctly on Panel version 0.13.1.
Each time I receive a socket timeout in my web browser that looks like this:
FWIW, the Bokeh docs at https://docs.bokeh.org/en/latest/docs/reference/settings.html#allowed-ws-origin do still list BOKEH_ALLOW_WS_ORIGIN
Complete, minimal, self-contained example code that reproduces the issue
Stack traceback and/or browser JavaScript console output
There is no panel traceback. This is the browser console output:
Screenshots or screencasts of the bug in action