cc @BrunoQuaresma

Hmm... it seems the timings are being added as the agent's lifecycle is set to ready. 🤔 I will try to figure out a better way to refresh the timings when the agent is ready.

To solve this issue, we need to define when the agent timings are ready to be displayed. I’m considering the following logic:

• The agent is marked as ready.
• If the agent has scripts, check that timings for each script are present.
• If the script timings aren’t present, continue refetching until they are available.

Could we perhaps always show the timings, and when there's an update: prompt the user to refresh?

Since this is such a long-running process, I think we need to be able to show intermediate phases. If we did the above we could simply poll, and if the state (i.e. timings JSON) has changed since the currently visible state then prompt. WDYT?

@dannykopping, it makes sense. @chrifro, do you have any ideas on how we could show or have a "pending" state for the chart? Or at least for the "run startup scripts"?

Could we perhaps always show the timings

With "timings" do you mean the data under "provisioning"?

Would this work?

What happens when new data is available? Can we load it automatically or do we need to reload the page?

See Figma

@chrifro and @dannykopping, what do you think about this? I believe this provides more context to the user regarding why it is still loading.

@BrunoQuaresma looks good! The copy's grammar should be corrected to "Waiting for agent to become ready...".

When refetching the timings to progressively display the agent scripts, it causes a layout shift because the chart recalculates the best intervals to fit the bar sizes and inner elements. This issue looks strange and buggy. To avoid the layout shift, I see two options:

1. Display the timings only when all timings are available: This eliminates the need to recalculate intervals later.
2. Calculate intervals and sizes only on the first render: The downside is that without all the data, the chart may not determine the optimal sizes and intervals.

In my opinion, the first option is the most reasonable and safest. I suggest we move forward with it and, depending on user feedback, we can consider implementing the second option later. WDYT? @dannykopping @chrifro

Yeah I think the first option makes the most sense. You only really need to know the timing information retrospectively; there isn't much value in seeing it while the build is taking place.

I'm also for option 1 🤝 ✨