feat: add GET /api/transactions endpoint with filtering and summary - #78
Conversation
- List transactions with filters: account_id, source, direction, category, date range, search - Pagination via limit/offset (max 200) - GET /api/transactions/summary/totals — aggregated by direction + category - GET /api/transactions/:id — single transaction lookup Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
chittycommand-ui | d3986bb | Apr 06 2026, 04:00 PM |
|
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughA new transactions API module is introduced with three GET endpoints for retrieving transaction lists, summary statistics, and individual transaction details. The module is registered in the main application router at Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
To use Codex here, create a Codex account and connect to github. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d3986bba6c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const limit = Math.min(Number(c.req.query('limit')) || 50, 200); | ||
| const offset = Number(c.req.query('offset')) || 0; |
There was a problem hiding this comment.
Validate and clamp pagination bounds
The pagination parsing accepts negative values (?limit=-5 or ?offset=-1) and passes them straight into LIMIT/OFFSET, which causes PostgreSQL to error and the request to fall through the global 500 handler. This makes a simple malformed query string trigger an internal server error instead of a client error; clamp both values to non-negative integers (or return 400 for invalid input) before issuing SQL.
Useful? React with 👍 / 👎.
| WHERE (${accountId}::uuid IS NULL OR account_id = ${accountId}::uuid) | ||
| AND (${source}::text IS NULL OR source = ${source}) | ||
| AND (${direction}::text IS NULL OR direction = ${direction}) | ||
| AND (${category}::text IS NULL OR category = ${category}) | ||
| AND (${from}::date IS NULL OR tx_date >= ${from}::date) |
There was a problem hiding this comment.
Reject malformed typed filters before SQL casting
This route casts raw query strings directly to uuid/date in SQL, so malformed inputs like account_id=not-a-uuid or from=2026-99-99 raise database cast errors and return 500s via the global error handler. These are user-controlled filter parameters, so they should be validated up front and rejected with 400 rather than crashing request handling.
Useful? React with 👍 / 👎.
Summary
GET /api/transactionswith filters: account_id, source, direction, category, date range, text searchGET /api/transactions/summary/totals— aggregated totals by direction + categoryGET /api/transactions/:id— single transaction lookupTest plan
/api/transactionswith no filters — returns all with pagination?source=mercury&direction=outflow— returns subset/api/transactions/summary/totals?from=2026-01-01— returns aggregated totals🤖 Generated with Claude Code
Summary by CodeRabbit