Bug: shared date range picker can break pages using preset or calendar selection

[niyazmft]

Problem

The issue is broader than Spending Analysis alone.

The shared date range picker can deliver inconsistent date value types into page-level consumers, which then causes runtime failures when those values are serialized.

Observed user-facing impact:

• preset selections such as Last 30 Days, Last 90 Days, This Month, Last Month, and This Year can break pages using the shared picker
• manual calendar selection can trigger the same class of failure on at least some affected flows
• the visible runtime symptom is a date serialization error during refresh logic

Root cause

This is a shared contract bug between the common picker and its consumers.

Historically, page-level handlers such as the one in SpendingAnalysisView.vue assumed they would receive Date objects and immediately passed them into formatDateForInput().

At the same time, the shared picker had paths where emitted values were not consistently normalized to Date objects.

That mismatch produced failures like:

TypeError: toISOString is not a function

Affected surfaces

Confirmed direct consumers of the shared picker include:

• frontend/src/views/SpendingAnalysisView.vue
• frontend/src/views/TransactionsView.vue
• frontend/src/components/Dashboard/HistoryPanel.vue

Because the contract is shared, this should be treated as a cross-page bug rather than a Spending Analysis-only issue.

Fix now present on main

The shared fix is present on main in commit ae3c0e0:

• DateRangePicker.vue now consistently stores and emits Date objects for picker flows
• utils.formatDateForInput() now safely accepts both Date and string values
• regression coverage was added for preset paths in frontend/tests/components/DateRangePicker.spec.js

Remaining validation needed

To fully close this class of bug with confidence, browser validation should confirm that the following all work without runtime errors:

• Last 30 Days
• Last 90 Days
• This Month
• Last Month
• This Year
• manual calendar-based date selection

across all pages using the shared picker.

Acceptance criteria

• no toISOString runtime errors from shared date range selection
• preset selection works on all shared-picker consumers
• manual calendar selection works on all shared-picker consumers
• test coverage exists for the shared contract and at least one page-level integration flow

[niyazmft]

Audit update based on current main:

Current code state

The shared date-picker fix is present in the latest code (ae3c0e0):

• DateRangePicker.vue now keeps preset values as Date objects instead of serializing them to strings.
• utils.formatDateForInput() now accepts both Date and string values.

What I verified

• Pulled latest main
• Reviewed:
  • frontend/src/components/Shared/DateRangePicker.vue
  • frontend/src/views/SpendingAnalysisView.vue
  • frontend/src/services/utils.js
• Ran frontend UI tests: pass
• Ran production build earlier: pass

Why issue #8 should remain open

Despite the shared fix, we now have a real runtime report from Spending Analysis showing:

TypeError: toISOString is not a function

That means there is still at least one in-browser path where a non-Date value reaches formatDateForInput() from the Spending Analysis flow.

The current code in SpendingAnalysisView.vue still assumes the picker payload can be passed through directly:

const handleDateRangeUpdate = ({ start, end }) => {
    fetchData(utils.formatDateForInput(start), utils.formatDateForInput(end));
};

So even though the shared picker contract was improved, Spending Analysis still does not explicitly normalize or validate the incoming payload before calling formatDateForInput().

Important testing gap

The existing UI tests only verify the shared picker component in isolation. They do not cover:

• SpendingAnalysisView.vue
• real PrimeVue DatePicker behavior in-browser on that page
• a full end-to-end date-change flow for Spending Analysis

So issue #7 appears to have fixed the shared preset bug, but issue #8 remains a valid page-level/runtime bug until Spending Analysis is proven safe in browser.

Recommended next fix

For issue #8, harden the page-level consumer and add a regression test:

1. Normalize incoming start/end values in SpendingAnalysisView.vue before use.
2. Add a page-level test covering date changes on Spending Analysis.
3. Verify both:
   • preset selection
   • manual date selection

Acceptance criteria update

This issue should be considered fixed only when:

• Spending Analysis date changes work in-browser without console errors
• preset and manual selection both refresh data correctly
• a regression test covers the Spending Analysis update flow

Side finding

Backend tests are still failing in test mode for an unrelated reason: backend/config/firebase.js throws when FIREBASE_SERVICE_ACCOUNT_KEY_JSON is missing before the NODE_ENV=test fallback can apply. That is separate from this issue.

[google-labs-jules]

Jules is on it. When finished, you will see another comment and be able to review a PR.

[google-labs-jules]

Ready for a review! A PR has been created.

[niyazmft]

Full analysis update based on the latest user report:

Summary

This is not just a Spending Analysis bug.

The failure pattern is consistent with a shared date-range contract issue affecting every page that consumes the common picker. The user report specifically expands the affected scope to:

• Last 30 Days
• Last 90 Days
• This Month
• Last Month
• This Year
• manual calendar selection paths as well

What I verified

1) Shared picker consumers

Current direct consumers of DateRangePicker.vue are:

• frontend/src/views/SpendingAnalysisView.vue
• frontend/src/views/TransactionsView.vue
• frontend/src/components/Dashboard/HistoryPanel.vue

2) Current root cause

The breakage came from inconsistent date value types crossing the shared picker boundary.

Page-level handlers were doing things like:

utils.formatDateForInput(start)

while earlier picker flows could provide values that were not consistently normalized to Date objects.

That is how you get the runtime failure:

TypeError: toISOString is not a function

3) Current code state on main

The repository already contains the shared fix in commit ae3c0e0:

• DateRangePicker.vue now emits/stores Date objects consistently
• utils.formatDateForInput() now accepts both Date and string inputs
• preset regression tests were added in frontend/tests/components/DateRangePicker.spec.js

4) Why the issue scope needed correction

Issue #8 was written as if the bug were limited to Spending Analysis. The new report shows the actual scope is broader and shared.

Recommendation

Treat this issue as the umbrella record for the shared date-picker runtime failure across pages, then verify in-browser that all listed presets plus manual calendar selection now behave correctly everywhere the picker is used.

If browser validation confirms main is clean, this issue can be closed as fixed by ae3c0e0 / PR #10.