π Description
Per the README, GET /api/v1/settlements?format=csv "ignores pagination and exports every matching, sorted row" β for a large settlement history, toCsv in src/utils/csv.ts currently builds the entire CSV string in memory before sending it, which doesn't scale and blocks the event loop during serialization.
π§© Requirements and context
- Stream the CSV response row-by-row (e.g. via
res.write per chunk) instead of materializing the full string.
- Preserve the exact same escaping behavior expected from the CSV-escaping fix elsewhere in this batch.
- Keep response headers (
Content-Type, filename) identical to the current export.
π οΈ Suggested execution
- Add a streaming variant of the CSV writer in
src/utils/csv.ts (or a new csvStream.ts) used by routes/settlements.ts.
- Add a test simulating a large settlement set and asserting the response streams incrementally (not just correctness of final content).
- Leave the anchors CSV export on the simple in-memory path unless it also proves large in practice.
β
Acceptance criteria
π Security notes
Reduces memory-exhaustion/DoS risk from a very large unpaginated export.
π Guidelines
- Minimum 95% test coverage
- Clear documentation
- Timeframe: 96 hours
π Description
Per the README,
GET /api/v1/settlements?format=csv"ignores pagination and exports every matching, sorted row" β for a large settlement history,toCsvinsrc/utils/csv.tscurrently builds the entire CSV string in memory before sending it, which doesn't scale and blocks the event loop during serialization.π§© Requirements and context
res.writeper chunk) instead of materializing the full string.Content-Type, filename) identical to the current export.π οΈ Suggested execution
src/utils/csv.ts(or a newcsvStream.ts) used byroutes/settlements.ts.β Acceptance criteria
π Security notes
Reduces memory-exhaustion/DoS risk from a very large unpaginated export.
π Guidelines