Feature/conversion check server

[interim17]

Problem

We want to ping the Octopus server to see if it is healthy before letting the user proceed too far along the auto-conversion workflow.

Closes #389

• New feature (non-breaking change which adds functionality)

Solution

This is the front end follow up to Alli's work, which set up the health check communication between the the Viewer and Octopus.

Reviewing this PR requires a dev build of the viewer, and a local instance of Octopus running, fun! A glimpse into the future.

Style things

I did a walkthrough of the modal styling with @lynwilhelm and have her approval on it. If you look at these designs you may notice that the auto-conversion designs are old and out of sync with the most current global style guidance.

For devs in review, if something on your machine looks/behaves dramatically wrong, or is vastly different than the screen shot, please let me know, but don't be too concerned about the design brief, Lyndsay and I are in touch about it all.

Hover state:

Code things

To check the server health we need to implement some logic to account for the fact that WebSocket requests don't have an automatic response if the request fails:

• first we now store conversionStatus in state: we were already storing status for the viewer in the Viewer Branch, I'm cloning that idea in the trajectory branch to track conversion status. I don't think VIEWER_IMPORTING was sufficient for this case, and I anticipate it will be useful to have a little granularity here going forward.

configureFileConversionLogic is where the action happens:

• check for a properly configured controller and set one up if needed

• then we define performHealthChecks a recursive function that will send a defined number of health check requests to Octopus, the health checks include a handler for when a positive response comes back, and a net connection config.

• a timeout waits a certain number of seconds before assuming the last check failed to get a response (would appreciate feedback on how long to wait here, thoughts in code comments)

• each handler goes out with a requestId and each requestId is stored along with a three second timeoutId in healthCheckTimeouts

• if a handler fires (meaning the server responded positively) we clear that set of ids from healthCheckTimeouts set healthCheckSuccesful to true and update conversionStatus to CONVERSION_SERVER_LIVE

• if a request times out with no response and healthCheckSuccesful is still false we try again until we reach MAX_ATTEMPTS and then set conversionStatus to CONVERSION_NO_SERVER

• this logic is triggered by the receiveFileToConvert action, which can be called with a null payload if we just want to do a health check

• ConversionForm sends a health check on load, and then another when a file is uploaded. If the conversionStatus is negative when we click the "Next" button, the modal should be raised.

Steps to Verify:

1. You need a dev build of the viewer installed in the website. Building from main will work. npm run build and copy the path of your viewer repo into package.json
2. You need an Octopus instance running locally at server ip "0.0.0.0" and port 8765, I can try to help you set this up if needed, @ascibisz is a also a wiz at this.
3. When your server is running, npm run start the website and go to http://localhost:9001/import or choose "import other file type" from the Load model menu.
4. Select Smoldyn for your conversion engine and upload any file that ends in .txt
5. Click next. If your server is running you should proceed to the next page, and also see a log of "conversion-server-live" in your console.
6. To test failure, repeat steps 3-6 without running your local Octopus instance. When you click Next you should see the error modal.
7. Similarly, if you turn octopus on between page load and file upload step, you should be able to advance.
8. Vice versa, if octopus is not running when you load the page, but then you turn it on, and then you upload a file, it should hopefully let you advance!

[meganrm]

Can you delete these and try to figure out how to keep them from happening? Are you adding spaces while you're typing that then get converted?

[interim17]

I've removed these and made a note for myself to look through the repo for these things and keep them from showing up.

[meganrm]

Do these need to be set back afterwards to enable someone to load a networked trajectory? Or does that happen automatically

[interim17]

I think in production we won't need to reset these because everything will use the same Octopus backend, and we will be able to remove this config and just use the same one for everything stored at the top of the file.

[meganrm]

have you tested initiating the config and then trying to load a networked file afterwards?

[interim17]

i did although i realize now it needs a little more work.
what i tested that works: currently if you navigate to /import and then to a trajectory url like /viewer?trajFileName=endocytosis.simularium it works.

but i now realize that, navigating to that url with the back button errors out, and if you hit /import then quickly navigate away while the server check is till pending there are some status setting side effects (i.e. the load trajectory button gets disabled while on the homepage for example) so i think i need to make this a bit more sophisticated in the logic and the router.

[ShrimpCryptid]

This is a good explanation, thank you! Maybe worth shortening this comment in-code though, since this seems like a comment for GitHub/PR

[interim17]

Indeed! I'll put a TODO flag at the top to make sure to cut it down before merging.

[ShrimpCryptid]

npm is warning about some dependency issues. May want to run npm audit fix.

[interim17]

A couple updates:

We were updating the viewer status toVIEWER_IMPORTING to disable some buttons in the app header but it was not working well because any trigger of VIEWER_ERROR status would reactive the buttons. We don't need it now that we have conversionStatus so I removed it entirely and also updated both of the status types based on @ShrimpCryptid 's feedback.

The redux initializeConversion() action is now handling the configuration and conversion so we were able to thin a little code from a few other places and it should be more semantic now. Thanks for the ongoing feedback!

[ShrimpCryptid]

Should this also be disabled when the status is SERVER_LIVE?

[interim17]

yes, this should be disabled if we are in any conversionStatus other than inactive

[ShrimpCryptid]

So currently this disables the load button if the user has the page open to the file conversion page, even if no file is selected... This is maybe because I don't have a local Octopus instance running, but the server not communicating probably shouldn't prevent users from being able to access the other import methods?

[interim17]

that's how ux wants it

[ShrimpCryptid]

Nit: I feel like this could be an enum...?

[ShrimpCryptid]

This or the constants

[interim17]

new issue opened, will address later

[ShrimpCryptid]

Copied over from another PR I accidentally commented on:

The cancel button is really faint when hovered.

Also, the delete button is invisible until hovering over the text filename.

[ShrimpCryptid]

Approving this, though I know there are more design discussions happening with UX. Feel free to re-request review if you do any other major changes.

I was able to test this locally (without Octopus) without issues, though I made a few notes about behavior and styling in the comments. It's worth having someone else who has a working Octopus install test this too.

[meganrm]

nit: you don't need the {"