fix: update cmr query key to cache bust on start and end date

[ifsimicoded]

Related Ticket:
Closes: #1897

Description of Changes

Updated the query key on the CMR time series stats endpoint to include start and end date for cache bust. This will refetch, even if the new date range stats was included in the prior fetch, so this isn't as optimized as it could be for caching. But this was the simplest approach without adding additional logic to check if the dates were exclusive of the previously set range.

Notes & Questions About Changes

Curious if there are other parameters missing in this query key that should be added?

Validation / Testing

This would impact any CMR dataset available for timeseries analysis. I tested using the original branch the bug was reported on as this branch provided the CMR dataset for testing. When going through every dataset available on veda-ui in my local env, I was unable to find a valid CMR dataset. I suggest pulling in the commit46eb610bd5d0e3f6eef29b8cf62a74d05e1b7ad8 from the bug report branch into your local to test.

[netlify]

✅ Deploy Preview for veda-ui ready!

Name	Link
🔨 Latest commit	67f796d
🔍 Latest deploy log	https://app.netlify.com/projects/veda-ui/deploys/69211b133924100008bbc51d
😎 Deploy Preview	https://deploy-preview-1928--veda-ui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[ifsimicoded]

I notice we don't use the formattedParamString in the query key. This leads me to believe it's desired that not all params should cache bust this query. In that case, are there any additional params I should add?

datasetData.timeInterval?

[dzole0311]

That's a good question!

For this dataset, the only parameters that actually vary with user interaction are start, end and the aoi.

datasetData.timeInterval?

timeInterval is a bit different. It’s a fixed prop of the dataset (eg. 'P1M' for monthly data) and comes straight from the config. With the current UI and architecture, users never change it and the backend (I think) doesn’t treat it as a dynamic input. Because of that, we don't have to include it in the key here.

[ifsimicoded]

this function is not used elsewhere. if functions are exported solely for tests, I suggest we prefix with private_ or _ so we can add a eslint rule to prevent imports of these functions outside of tests.

[dzole0311]

Thanks for the cleanup! I agree with removing the export. We generally rely on module scope (exported vs. non-exported) to signal privacy rather than using naming prefixes like private_.

I think if we ever need to reuse this logic elsewhere, we should extract it into a dedicated util file or custom hook at that point. But for now, keeping it non-exported here is perfect.

[dzole0311]

Tested with the Ozone Concentration CMR dataset:

1. Analysis runs correctly
2. Updating the time range and rerunning now works as expected

Thanks for the fix @ifsimicoded!

[dzole0311]

That's a good question!

For this dataset, the only parameters that actually vary with user interaction are start, end and the aoi.

datasetData.timeInterval?

timeInterval is a bit different. It’s a fixed prop of the dataset (eg. 'P1M' for monthly data) and comes straight from the config. With the current UI and architecture, users never change it and the backend (I think) doesn’t treat it as a dynamic input. Because of that, we don't have to include it in the key here.

[dzole0311]

Thanks for the cleanup! I agree with removing the export. We generally rely on module scope (exported vs. non-exported) to signal privacy rather than using naming prefixes like private_.

I think if we ever need to reuse this logic elsewhere, we should extract it into a dedicated util file or custom hook at that point. But for now, keeping it non-exported here is perfect.