ageller / Firefly

A WebGL interactive particle viewer
GNU Affero General Public License v3.0
65 stars 13 forks source link

fix for when GUI missing partsKeys #165

Closed ageller closed 1 month ago

ageller commented 1 year ago

Often when I run Firefly through flask it does not build the GUI, and the console message show GUI missing partsKeys. At that stage, the GUI never loads and Firefly cannot load. So the user is stuck at the loading screen with no information about what is happening (other than seeing building GUI). We should fix this so that there is some way to get out of the loop and make it load.

Maybe a fix could be if the GUI isn't built after some amount of time but the viewer thinks its done, then the GUI sends a signal to the viewer to request the initialization again.

agurvich commented 1 year ago

why is it missing parts keys? do you think the flask message got lost or is something in the viewer breaking before sending it to the GUI?

ageller commented 1 year ago

I'm not sure. And your two options above are the ones that I would consider as well. All I know is that this happens alarmingly regularly when I am running in a Jupyter notebook. Usually just rerunning iFrame cell makes it work the next time through.

agurvich commented 1 year ago

ah wow, so it's inconsistent? that's not a good sign.

ageller commented 1 year ago

It's possible that this happens if I don't wait long enough between launching the server and starting the iFrame. (?) I do wait until I see the full output of Waiting up to 10 seconds for background Firefly server to start...done! Your server is available at - http://localhost:5500/, but maybe I need to wait a bit longer in the notebook. I'll keep an eye on it.

agurvich commented 1 year ago

if that were the case then the iframe would 404 because there's no server to give it the firefly files

ageller commented 1 year ago

Maybe the server exists but all the sockets haven't connected yet?

agurvich commented 1 year ago

weird. if you split the GUI and the viewer you might get an error message in the viewer that is being suppressed somehow in combined

ageller commented 1 year ago

This is hard to debug because it doesn't happen every time. But it seems like it happens most often when I

  1. start a jupyter notebook
  2. start a server in the notebook
  3. start an iFrame in the notebook to the combined endpoint
  4. (optional) open the developer tools

Doing all that in quick succession seems to cause this bug.

It looks like it is coming because firefly doesn't connect to the server. I don't see any messages about joining rooms, etc. I'll keep digging.

ageller commented 1 year ago

It seems like the best (only?) fix for this is to reload the page. I put this in, though it might result in some infinite loop of reloads. Though I suppose this may be better than having the page stuck at loading...

ageller commented 1 year ago

That console output of missing partsKeys is telling us that the GUI hasn't been sent the data it needs. But the problem is likely on the viewer side somewhere. (We're seeing a symptom but not the root cause.) This does seem like something that we should get to the bottom of and fix as a top priority.

In the meantime, it might be worthwhile adding some output to the screen in a circumstance like that that says something like "Firefly encountered an error loading the data, please reload your browser. If that doesn't work, please try clearing your browser cache or running Firefly an incognito browser window."

ageller commented 1 year ago

I think this may be solved, currently in the data_selectionbranch. From my testing it appears (at least on my end) that when I reload the browser when using flask, the browser still thinks that it is connected to the socket. So the socket's 'connect' check is never fired in JS (for either the GUI or the viewer). This then doesn't define the room and then no messages get passed. So, I added some flags to the socket.io connection :

this.socket = io.connect(location.protocol + '//' + document.domain + ':' + location.port + this.namespace, 

{
    rememberTransport: false,
    transports: ["websocket"],
    forceNew: true,
    reconnection: true,
});

Now it seems to connect every time I reload the page. We should update this in the main branch as well (or wait until this branch is merged into main.)

ageller commented 1 month ago

I think this is fixed, especially with the changes in v3.3.1. I will close this (at least for now).