Adds field-scoped date range filtering to the cache runs endpoint so reporting clients can request runs within a specific execution window without walking the full history.
What changed
- Added a
ran_at query filter object to the cache runs listing endpoint.
- Supports
ran_at[gt], ran_at[gte], ran_at[lt], and ran_at[lte] with Unix timestamps in seconds.
- Invalid negative or out-of-range timestamp filters now return a bad request response with a concrete message.
- Cache run responses now serialize
ran_at from the stored ran_at value instead of deriving it from created_at.
- Regenerated the server contract and Swift command-line client files, including handling for the new bad request response.
Why
Cache hit-rate reporting needs to ask for cache runs inside a time window. Without a date range filter, clients have to paginate through all cache run history and bound the result set themselves.
Approach
The filter shape follows the field-scoped operator style used by Stripe list filters. Applying the operator to ran_at keeps the parameter explicit today and leaves room to add other date fields later without introducing new top-level names for every range.
Impact
Clients can request cache runs by execution window while existing git reference, branch, commit, and pagination filters keep working. The generated Swift client now exposes a typed ran_at query payload and surfaces validation failures from the server.
Screenshots
Not applicable. This changes a JSON endpoint and generated command-line client files, with no browser-rendered surface to capture before and after.
How to test locally
mix test test/tuist_web/controllers/api/cache_runs_controller_test.exsmise run generate-api-cli-codetuist generate tuist ProjectDescription --no-openxcodebuild build -workspace Tuist.xcworkspace -scheme tuist CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY=""git diff --check
T
