Configurable history window for forecast and actuals (Closes Issue #655) #670
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR implements a configurable history window for both nowcasting-app and quartz-app, allowing users to control how far back in time the UI fetches forecast and actual data. This implementation addresses the issue completely for both apps and fixes all the mistakes from previous attempts. This PR supersedes #657, #659, and #660, consolidating the logic into a robust solution with full test coverage and environment validation.
Overview
Previously, the apps used hardcoded values to fetch the last 48 hours of data. This PR makes the history window configurable via environment variables, supporting two modes:
Implementation
Environment Variables
Both apps now support:
Nowcasting App
Modified Files:
components/helpers/data.ts
components/helpers/historyConfig.test.ts (NEW)
.env.example
Quartz App
Modified Files:
src/helpers/historyWindow.ts (NEW)
src/data/queries.ts
start_datetime_utcparameterstart_datetime_utcparameteras anytype assertion for API parameter (schema doesn't define it yet)src/helpers/historyWindow.test.ts (NEW)
.env.example (NEW)
Improvements
This PR addresses several limitations identified in previous iterations:
nowcasting-appandquartz-app(forecasts and actuals).start_datetime_utc, and added full unit test suites.Testing
What I Verified
For Maintainers to Verify
As I do not have Auth0 credentials or live API access, please verify:
start_datetime_utcparameterType Safety Notes
The TypeScript warnings about
start_datetime_utcnot existing in the query types are expected. The API accepts this parameter (as evidenced by previous PR attempts and API schema comments), but the TypeScript types haven't been regenerated to include it. Usingas anyis a pragmatic solution until the types are updated.Note on Build Failures
I noticed the repository contains some existing formatting inconsistencies (CRLF vs LF) in unrelated files. I have ensured my changes are properly formatted (verified via yarn lint --fix on modified files), but the build system might flag pre-existing linting issues in other parts of the codebase.