fix Cluster Dashboard timerange filtering in Financial Overview

[munyanezaarmel]

… working as expected

Brief summary of the change made

This PR addresses the unintuitive behavior of the financial data display in the Dashboard. It resolves three key issues:

1. Initial Data Loading: The "Refresh Data" button is no longer required for initial data loading. The Dashboard now automatically fetches and displays the most recent data upon opening. This provides a more seamless user experience and eliminates the confusion surrounding the button's inconsistent behavior. The underlying logic for data fetching has been reviewed and optimized to ensure consistent and reliable initial loading.

2. Consistent Time Range: The initial time range for all charts is now consistently set to 3 months, matching the default selection. This eliminates the discrepancy between the selected range and the displayed data in the line chart. The time range selection now correctly drives the data displayed in all three charts.

3. Unified Filtering: The time range filter now applies consistently to all three charts. Changing the time frame now updates the data displayed in all charts, providing a unified and expected filtering experience.

closes: #432

Are there any other side effects of this change that we should be aware of?

Describe how you tested your changes?

Pull Request checklist

Please confirm you have completed any of the necessary steps below.

• Meaningful Pull Request title and description
• Changes tested as described above
• Added appropriate documentation for the change.
• Created GitHub issues for any relevant followup/future enhancements if appropriate.

[beesaferoot]

A quick check on the dashboard shows some data isn't displayed (top row summary). Can you check why?

[dmohns]

A quick check on the dashboard shows some data isn't displayed (top row summary). Can you check why?

Yeah, same issue for me! On initial load the top row is empty.

I also noticed, that on initial load the map is not populated. Only after a couple of refreshes/button clicks this happens.

[beesaferoot]

I figured the issue was from the backend; the endpoint /api/dashboard/clusters GET request only uses the cache. So the first request usually will not have the cached data, which causes the server to respond with empty data.

I traced it to the ClustersDashboardCacheDataController

Modifying the logic to ensure the cache has been populated before returning resolves the issue.

 public function index() {
        $cachedData = $this->clustersDashboardCacheDataService->getData();
        if (empty($cachedData)) {
            $this->clustersDashboardCacheDataService->setData();
        }

        return ApiResource::make($this->clustersDashboardCacheDataService->getData());
    }

@munyanezaarmel @dmohns

[munyanezaarmel]

Thanks, @beesaferoot! I was thinking the same thing that the issue might be coming from the backend. Initially, I thought the first request was taking too long, causing a timeout and resulting in a delay, which is why you had to send a second request (by clicking the "Reload Data" button). Thank you so much for looking into this! You can check it again now.

cc: @dmohns

[munyanezaarmel]

@dmohns, what do you mean by "map is not populated"? Could you provide more context?

[dmohns]

fix clusterdashboard cached data

Great find! Out of curiosity... Where you able to understand "why" we are doing that caching in the first place? It seems like the cluster data wouldn't be that massive 🤔

[dmohns]

@dmohns, what do you mean by "map is not populated"? Could you provide more context?

This is what it looks like to me ☝️ The map is empty and doesn't show any clusters/minigrids

[munyanezaarmel]

@dmohns, what do you mean by "map is not populated"? Could you provide more context?

This is what it looks like to me ☝️ The map is empty and doesn't show any clusters/minigrids

@dmohns, this is how it appears on my end. Could you confirm that you're on the correct branch? I also noticed that the financial overview data has not yet been fixed on your side

[munyanezaarmel]

Great find! Out of curiosity... Where you able to understand "why" we are doing that caching in the first place? It seems like the cluster data wouldn't be that massive 🤔

Yes, I looked into it, and from what I can tell, the caching is likely implemented to improve response times and reduce unnecessary database queries. Even if the cluster data isn’t massive, fetching it dynamically on every request could introduce latency, especially if there are complex joins or calculations involved.

That said, if the dataset isn't frequently updated, a more efficient approach might be to populate the cache proactively rather than relying on the first request to trigger it. Do you have any insights into the initial reasoning behind this caching strategy?

[dmohns]

This is an amazing change, thanks both of you 🙏

[dmohns]

Great find! Out of curiosity... Where you able to understand "why" we are doing that caching in the first place? It seems like the cluster data wouldn't be that massive 🤔

Yes, I looked into it, and from what I can tell, the caching is likely implemented to improve response times and reduce unnecessary database queries. Even if the cluster data isn’t massive, fetching it dynamically on every request could introduce latency, especially if there are complex joins or calculations involved.

That said, if the dataset isn't frequently updated, a more efficient approach might be to populate the cache proactively rather than relying on the first request to trigger it. Do you have any insights into the initial reasoning behind this caching strategy?

@munyanezaarmel Could you please create a follow-up issue to investigate and improve our caching strategy? You can link this one for context.

[munyanezaarmel]

@dmohns, here is the issue. You can check it and let me know your thoughts: #483