Loading spinner disappears after first render, then reappears

[K20shores]

Describe the bug After clicking the Run Model button, you are taken to the results screen /results. A loading spinner appears while the server is working, but then it disappears and text that shouldn't appear while a model is running appears. Then the spinner reappears.

To Reproduce Steps to reproduce the behavior:

1. Go to https://musicbox.acom.ucar.edu/
2. Click on Get Started
3. Click on Select under Chapman Cycle
4. Click on Run Model
5. Observe the flicker

Expected behavior The spinner should be displayed the entire time the model is running

Screenshots

Additional context

Important files:

• src/components/Layout.jsx, this is where the Run Model button is. The run click handler dispatches an UPDATE_RUN_STATUS event, and calls doRun which is in src/redux/actions/run.js
• src/redux/actions/run.js, Translate the current configuration to what the server needs to run and calls the run api endpoint
• src/controllers/api.js, this has the run call
• src/redux/middleware/polling.js, this is where we poll for the status and dispatch UPDATE_RUN_STATUS events
• src/redux/reducers/results.js, handles updating the redux store with the new run status
• src/pages/results.jsx, handles displaying the spinner

Run Model workflow In general this is what happens when you poke run, to the best of my ability to understand what happens.

Click "Run Model" -> Reset the plot information -> Set the run status to Running -> Call doRun -> Call run on the API server -> Dispatch a START_POLLING event -> The polling middleware should receive the START_POLLING event -> navigate to /results

What may be happening is that the status gets set to RUNNING by the Run Model callback, then updated again to WAITING in the first response to check the results in the poll function, then the next polling event sets it to RUNNING and the spinner updates. Indeed, if you open up the chrome console and look at the response for run-status, the first is WAITING and the second is RUNNING. So, what probably needs to happen is that callback fro RUn Model needs to set the status to WAITING

However, it would be nice for the spinner to show always after clicking Run Model until an error or results come back

To run the server to get model results, see our readme

[wes-q]

Is this issue resolved? I can't reproduce the bug.

Screencast from Saturday, 23 December, 2023 12:00:22 PM PST.webm

[K20shores]

@iamwesofph you don't seem to be connected to a dev API server or the production one. Without that, you won't actually be getting any results back and wouldn't see the issue. Please check the chrome console; you'll likely see the API calls fail. Our readme states how to setup with either a dev or production API server. However, if you need help, I can provide more insturctions or guidance here. Thank you for your time!

[wes-q]

I actually setup the dev server using: VITE_API_URL='https://musicbox.acom.ucar.edu/musicbox'

Screencast from Saturday, 23 December, 2023 01:55:49 PM PST.webm

[K20shores]

@iamwesofph. If you are connected to the prod server, when you click on the chapman example you would see a list of species appear, like in the gif in the issue. I've confirmed that this is still an issue for me client side hitting the production server. I'm unclear about why the server connection would fail for you, likely an nginx configuration or something that's preventing this. It does appear that you are connected though. Strange

If you are interested, you could setup a development server on your machine:

• Change VITE_API_URL back to http://localhost:8000
• git clone https://github.com/NCAR/music-box-interactive-api.git
• cd music-box-interactive-api
• docker compose build && docker compose up -d && docker compose logs -f

However, I understand if that seems like too much work.

[K20shores]

@iamwesofph I did check our metrics and appear to see activity that looks like what is in your screencast. It appears there's some bug preventing you from seeing the results of the API calls, but I'm unclear why I don't see the same behavious as you.

As an alternative to setting up a local dev server, and if since you seem to be connected to the prod server, you could setup a simple reaction yourself while connected to the prod server.

1. Click Get Started
2. Click Start from scratch
3. Enter A into the species box
4. Click on Reactions -> Emission
5. Click on the <none> -> <none> text
6. Next to species click on <select> and choose A
7. In the sidebar, click on Conditions
8. Click on Initial
9. At the bottom, in the Reaction Rates and Rate Constants click on the +
10. Click on the select box under Reaction Label
11. Choose <none> -> A
12. Give it an Initial value of 0.01
13. Give it units of mol m-3 s-1
14. Click run

Then you will hopefully see the issue and also have run your first atmospheric box model chemical system

[wes-q]

Hi, what do you mean server connection failed me? Also, what results of the API calls am I not seeing?

Im just trying to replicate the bug issue where the spinner flickers because it shows this part:

const ResultsNotStarted = () => {
    return (
        <>
            <h1>To run a simulation, click the green Run button to the left</h1>
            <p>The possibilities are limitless.</p>
        </>
    );
};

[wes-q]

I was also following your steps you outlined but I cant find these:

Click on Conditions Click on Initial Add the bottom, in the Reaction Rates and Rate Constants click on the + Click on the select box under Reaction Label Choose -> A Give it an Initial value of 0.01 Give it units of mol m-3 s-1

[K20shores]

@iamwesofph apologies, I didn't' realize my previous comment was improperly formatted.

You've correctly added an emissions reaction. In the left sidebar, there's a link to the Conditions page. On that page you'll see a tab called Initial. At the bottom of the Initial tab is where you'll find the Reaction Rates and Rate Constants.

I've fixed the instructions above, hopefully you can get it from there. Thanks for trying this out!

[K20shores]

Hi, what do you mean server connection failed me? Also, what results of the API calls am I not seeing?

Im just trying to replicate the bug issue where the spinner flickers because it shows this part:

const ResultsNotStarted = () => {
    return (
        <>
            <h1>To run a simulation, click the green Run button to the left</h1>
            <p>The possibilities are limitless.</p>
        </>
    );
};

After you click on the Chapman example, you should see a number of species besides M. You can check in the network tab of chrome if the load-example call returned any json. The output is too long to post, but it should be ~ 319kB of information. If you do see json returned, then for some reason the client side is not populating the redux store for you, which is odd.

[wes-q]

If you try, the list doesn't load when you click the mechanism tab at the left.
This could be another issue if it's not the intended way your app works. It improves user experience if the user does not have access to confusing mechanism (like when the user shortcuts to clicking "mechanism" instead of starting from "start here").

Proposed solution: a) Remove the mechanism shortcut b) Load the default examples when user first clicks "mechanism"

[wes-q]

Screencast from Sunday, 24 December, 2023 07:46:38 AM PST.webm

Unfortunately, I still can't reproduce the bug issue you're facing. I tested this multiple times using npm run dev, npm preview, and the link https://musicbox.acom.ucar.edu/

Have you tried using another workstation and browser to replicate the issue?

[wes-q]

Even though I cannot replicate the bug, its quite clear what is causing the flickering issue you're describing (as I am seeing from the very quick GIF you attached).

This is the related code:

   <Layout>
      <Container className="jumbotron text-center hero-img">
        {(() => {
          switch (runStatus) {
            case RunStatus.RUNNING:
              return <ResultsRunning updateCount={renderCount.current} />;
            case RunStatus.DONE:
              return <ResultsDone />;
            case RunStatus.ERROR:
              return <ResultsError errorMessage={error.message} />;
            case RunStatus.WAITING:
              return <ResultsNotStarted />;
            case RunStatus.NOT_FOUND:
              return (
                <ResultsError errorMessage="Unexpected server error. Please try your run again." />
              );
            default:
              console.error(`Unknown model run status: ${runStatus}`);
              return <ResultsNotStarted />;
          }
        })()}
      </Container>
    </Layout>

On your case, this is the RunStatus' status: RunStatus.RUNNING >> RunStatus.WAITING >> RunStatus.RUNNING >> RunStatus.DONE

From my perspective, I can't think of a scenario of why we need the runStatus.WAITING because the event automatically happens when the user clicks the RUN button.

Proposed solution: Remove the runStatus.WAITING functionality, if it is not used elsewhere.

[K20shores]

@iamwesofph there are three examples the users can choose from. Going straight to the mechanism tab works only if you want to build up the mechanism by hand.

I've seen this issue on two separate computers, and my coworker has also mentioned it. Perhaps it's a difference in internet speeds or something?

As for why we we have the waiting state, the chemical systems themselves can take quite awhile to run and we only have the capacity to run three at a time. When you click the run button, your data gets placed into a queue of models to run and may not be run immediately. In fact, we've seen this when we tested with ~10 scientists at one time.

I believe the bug is because the Layout component initially sets the state to RUNNING, the server can respond and say the status is actually waiting, so the Layout component shouldn't assume we will start in a RUNNING state and should instead set the status to WAITING.

However, you're correct that the results screen doesn't actually show any useful information when it's in a waiting state. Would you consider fixing the bug in the Layout component and, when on the results page and in the WAITING state, showing something like "We've queue your run request! A loading indicator will appear when your box model begins its simulation" or something like that.

[wes-q]

Perhaps it's a difference in internet speeds or something?

I don't think so, I tried using Slow 3G speeds. As long as the API returns a WAITING state, then the message will display therefore the flicker effect.

A loading indicator will appear when your box model begins its simulation" or something like that.

Can you be specific of what kind of loading indicator you want to see? From my perspective, as a user, I just want to see the spinner if the app received my command. But its my opinion.

However, it would be nice for the spinner to show always after clicking Run Model until an error or results come back

I'm more inclined to make this work for you instead, if you agree. But first I want to recreate the bug. Do you have an idea on what input might cause a WAITING state?

[wes-q]

Just so were on the same page, this is what WAITING state displays:

Do you really need this? Because the user already clicked the run button. Also if I make the app display "We've queue your run request!", when will it be transitioned into a spinner?

[K20shores]

@iamwesofph that text is not needed for sure. It would be better to have something that indicates the difference between a simulation waiting to run and then the spinner which is when it's actually running.

[K20shores]

@iamwesofph a waiting state is sent back by the server when the simulation is waiting to run

Here are three screen shots that show the results of api/run and api/run-status

[wes-q]

@iamwesofph that text is not needed for sure. It would be better to have something that indicates the difference between a simulation waiting to run and then the spinner which is when it's actually running.

Isn't this the indication that the simulation is waiting to run?

Thanks for sending the screenshots of the network tab. The first WAITNG status coming from "run" does'nt really generate the waiting message (To run a simulation click the green button on the left). The second WAITING status from the second picture coming from "run-status" is the one generating the waiting message, and that is also the one data I still cannot replicate/reproduce. So I'm looking at the backend/server API now to check the logic of the code.

My initial thoughts and gut feel tells me that the run-status API is unnecessary, the original "run" API can simply return data that tells the frontend that the simulation has finished, eliminating the need for doing multiple HTTP requests ("run-status) polling for the status of the original HTTP request ("run). I may be wrong though, so I will check the codebase first but calling an HTTP request every second seems fishy to me.

[K20shores]

@iamwesofph The chapman model is relatively small and doesn't take too long to finish. If you run the full gas phase example, you should have to wait several seconds before results appear. After pressing run, results won't be returned immediately, so we do need to poll the server (at least until we implement #208). These simulation times can be controlled on the condition page; adding more fine-grained time steps or increasing the total runtime of the simulation will lengthen the time to results.

This simulation runtime is not something that the API server or the client code can control. We will in the hopefully not so distant future be switching to a different ODE solver in our box model code, which should speed things up noticeably. However, even with that, results won't be immediate.

[wes-q]

Hello, can you help me reproduce this issue? How do I run the full gas phase example? I already tried the quoted instruction below that you gave me, but it didn't reproduce the issue.

I also tried using development mode, and production mode. I tried setting the VITE_API_URL='https://musicbox.acom.ucar.edu/musicbox', and i also tried running my own API server following your instructions on the README.md file, but I am getting errors. Can we chat somewhere to get things going?

Click Get Started Click Start from scratch Enter A into the species box Click on Reactions -> Emission Click on the -> text Next to species click on and choose A In the sidebar, click on Conditions Click on Initial At the bottom, in the Reaction Rates and Rate Constants click on the + Click on the select box under Reaction Label Choose -> A Give it an Initial value of 0.01 Give it units of mol m-3 s-1 Click run

K20shores commented 8 months ago

Hi @iamwesofph , the third example on the getting started page is the full gas phase example.

You can also verify that you're getting results by navigating to the plots page. For the Chapman example, plotting O1D should show you peaks and troughs. Other species are constant or have such a small change that their values look like a flat line for that example.

wes-q commented 8 months ago

I ran the full gas phase and got around 20+ "run status" network calls and I didn't get a single response with "WAITING". Every single request returned a "RUNNING" response, and then finally a "DONE" response.

So again, I cannot reproduce the bug, which is the first step before I can fix the issue.

K20shores commented 8 months ago

@iamwesofph it does not always happen this way. You appear to be lucky enough to never have the waiting status, but it can happen, as evidenced by my screenshot earlier.

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[K20shores]

Hi @iamwesofph , the third example on the getting started page is the full gas phase example.

You can also verify that you're getting results by navigating to the plots page. For the Chapman example, plotting O1D should show you peaks and troughs. Other species are constant or have such a small change that their values look like a flat line for that example.

[wes-q]

I ran the full gas phase and got around 20+ "run status" network calls and I didn't get a single response with "WAITING". Every single request returned a "RUNNING" response, and then finally a "DONE" response.

So again, I cannot reproduce the bug, which is the first step before I can fix the issue.

[K20shores]

@iamwesofph it does not always happen this way. You appear to be lucky enough to never have the waiting status, but it can happen, as evidenced by my screenshot earlier.