[Ahmad12developer]

Summary

Implements optional from and to ISO 8601 time range filtering for the getPriceHistory GraphQL query, documents boundary inclusivity in the schema description, and enforces point cap bounds matching the REST route.

Fixes

Fixes #370

Details of Changes

1. Schema & Documentation:
   • Added optional from: String and to: String arguments to getPriceHistory in the GraphQL schema.
   • Documented boundary inclusivity in the schema description: the range is inclusive at both ends (bucket >= from AND bucket <= to), noting that adjacent query windows intentionally share boundary buckets.
2. Input & Bound Validation:
   • Validated from and to as ISO 8601 timestamps, rejecting invalid date strings with descriptive error messages.
   • Enforced that from must be before or equal to to, rejecting inverted ranges (from must be before to).
   • Enforced MAX_HISTORY_POINTS (10,000) cap matching the REST /prices/history route to prevent unbounded DB scans over large time spans at fine resolutions.
3. Database Querying:
   • Dynamically parameterized the PostgreSQL query in src/api/graphql.ts to add bucket >= and bucket <= conditions when provided.
   • Preserved default descending order and capped limit at 1000.
   • Maintained full backward compatibility for queries without from or to.
4. Testing:
   • Added comprehensive integration test suite in src/__tests__/graphqlPriceHistory.test.ts verifying:
     • Schema description explicitly documents boundary inclusivity and arguments.
     • Rejection of invalid from and to strings.
     • Rejection when from is after to.
     • Rejection of over-large windows exceeding MAX_HISTORY_POINTS.
     • Successful querying and parameter mapping for valid bounded ranges.
     • Single-bound and legacy queries without from/to.
   • Verified all 647 unit/integration tests pass with zero regressions.

Checklist

• from and to are supported and validated
• An over-large range is rejected rather than served
• from after to is an error
• Boundary inclusivity is documented in the schema description
• Tests cover a bounded range, an invalid range and an over-large one
• All 647 test cases pass cleanly (npm test)

[Miracle656]

Needs a rebase — main moved six times this morning (#379, #380, #382, #392, #401, #310 all landed) and this now conflicts. Push a rebase and I will pick it up; nothing is queued ahead of it.

[Ahmad12developer]

Resolved merge conflicts with latest upstream/main and integrated with GraphQL error masking. All 673 tests passing and build succeeds. @coderabbitai review

[Miracle656]

Every criterion met, and one of them met in the way I actually wanted rather than the way that was easiest.

Boundary inclusivity is stated, not assumed. The schema description says it outright and names the consequence:

The time range is inclusive at both ends… Because both endpoints are inclusive, querying adjacent windows (e.g. [t0, t1] and [t1, t2]) will…

That was the point of the criterion. Range queries in this codebase are inclusive at both ends, so adjacent windows double-count the boundary — and the failure mode is that nobody notices until a sum is quietly wrong. Writing it into the schema puts it in front of the one person who can act on it, and documents boundary inclusivity in the schema description is a test that keeps it there.

The cap is imported, not reimplemented. HISTORY_INTERVAL_SECONDS and MAX_HISTORY_POINTS come from ./history, so GraphQL and REST cannot drift into disagreeing about how large a window is too large. Copying the constant is the obvious shortcut and it is how two surfaces end up with different limits that nobody can explain a year later.

The test set covers the right shapes too — invalid from, invalid to, from after to, an over-large range, a bounded range asserting the query really is inclusive, only-from, and legacy calls with neither argument. That last one is what says existing clients still work.

Merging.