Payment date filters are unvalidated: date_from after date_to ships to the backend and returns confusing results

[usmanimamu17-create]

Problem

PaymentsView (src/components/payments/payments-view.tsx) passes the raw date inputs to the API:

<input type="date" value={dateFrom} onChange={(e) => { setDateFrom(e.target.value); setPage(1); }} />
...
fetchPayments({ ..., date_from: dateFrom || undefined, date_to: dateTo || undefined, ... })

There is no check that date_from <= date_to. Consequences:

• A reversed range reaches the server: the operator picks From = 2026-08-10 and To = 2026-08-01 (or the fields auto-fill inconsistently); the backend either returns an empty list or a validation error whose message is backend-shaped, with no client-side guidance.
• The two inputs are independent: nothing disables or flags the invalid combination, so the operator discovers the problem only by the (possibly empty) result — indistinguishable from "no payments in range".
• The same pattern will be reused: the export path (handleExport) forwards the same unchecked values to exportPayments, so a reversed range exports an empty file with no warning.

Root cause

The filter bar was built with bare date inputs and no cross-field validation.

Why this is architecturally hard

1. The fix is a derived isRangeInvalid = dateFrom && dateTo && dateFrom > dateTo check with an inline message and a disabled/flagged state — small, but the pattern (cross-field validation for paired filters) should be a reusable form component, since the outages and dashboard filters will grow the same pairs.
2. The empty-result ambiguity (no data vs. bad range) matters for UX copy: the empty state text should distinguish the two when the range is known-invalid.
3. The export path must share the guard so exports cannot be run with a reversed range — the two call sites must stay in sync.

Proposed design

Add a cross-field range check in PaymentsView (inline error, applied to both the list fetch and the export), render the empty state distinctly when the range is invalid, and add tests for reversed and equal ranges.

Acceptance criteria

Service

• A reversed date range is flagged inline and not submitted as-is.
• The export path respects the same guard.

Tests

• A test asserts a reversed range blocks the fetch.
• A test asserts equal bounds are accepted.

Out of scope

The React Query migration and URL-state sync (tracked separately).

Getting started

npm test -- payments-view

Good first files to read: src/components/payments/payments-view.tsx, src/services/paymentService.ts.

[waterWang]

Implemented in PR #433 — adds a cross-field date_from <= date_to check that blocks the fetch and the export for a reversed range, flags it inline (red border + alert), and renders a distinct invalid-range empty state. tests/payments-view.test.tsx 10/10 passing.

[nottherealalanturing]

@nottherealalanturing has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi there, I'd like to contribute to this.

This touches React, which I have hands-on experience with. I'll implement this following the existing conventions in the codebase, with tests covering the new behavior.

I'd love the opportunity to work on this — please consider assigning it to me.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @nottherealalanturing to this issue.

[drips-wave]

Congratulations, @nottherealalanturing! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @nottherealalanturing: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[drips-wave]

This issue has been completed by @nottherealalanturing as part of the Stellar Wave Program's 8th Wave 🥳

😎 @nottherealalanturing: You earned 200 Points for completing this issue! After the current Wave ends, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.

🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.