Description:
The batch history and live progress APIs are central to the dashboard experience but lack dedicated HTTP-level tests. GET /api/batch-history returns paginated job summaries from SQLite, and GET /api/batch-events/:jobId streams Server-Sent Events until a terminal job status. Neither endpoint has coverage under tests/, unlike batch-submit and tx-status routes.
SSE introduces unique testing concerns: correct text/event-stream headers, periodic payloads, stream closure on completed/failed, and auth via publicKey. History filtering by status, network, date range, and search also needs regression protection after changes to getAllJobs and countJobs.
Context & Impact:
Dashboard history and real-time progress are user-visible contracts. Breaking pagination metadata, leaking another user's jobs, or hanging SSE streams degrades trust and increases server load from clients that never disconnect.
Steps to Reproduce / Failure Mode:
- Request
/api/batch-history without publicKey—expect 400; verify behavior is tested.
- Open
/api/batch-events/{jobId}?publicKey=... for a processing job—expect repeated data: frames until completion.
- Change
serializeJobEvent shape without tests—frontend hooks silently break.
Proposed Solution:
- Add
tests/batch-history-api.test.ts seeding jobs via job-store helpers and asserting pagination, filters, and response shape.
- Add
tests/batch-events-api.test.ts using Vitest fetch or route handler invocation, collecting streamed chunks until close.
- Test 400 paths for missing/invalid
publicKey and unknown jobId.
- Document expected JSON payload fields shared with
useBatchPolling.
Acceptance Criteria:
Description:
The batch history and live progress APIs are central to the dashboard experience but lack dedicated HTTP-level tests.
GET /api/batch-historyreturns paginated job summaries from SQLite, andGET /api/batch-events/:jobIdstreams Server-Sent Events until a terminal job status. Neither endpoint has coverage undertests/, unlike batch-submit and tx-status routes.SSE introduces unique testing concerns: correct
text/event-streamheaders, periodic payloads, stream closure oncompleted/failed, and auth viapublicKey. History filtering by status, network, date range, and search also needs regression protection after changes togetAllJobsandcountJobs.Context & Impact:
Dashboard history and real-time progress are user-visible contracts. Breaking pagination metadata, leaking another user's jobs, or hanging SSE streams degrades trust and increases server load from clients that never disconnect.
Steps to Reproduce / Failure Mode:
/api/batch-historywithoutpublicKey—expect 400; verify behavior is tested./api/batch-events/{jobId}?publicKey=...for a processing job—expect repeateddata:frames until completion.serializeJobEventshape without tests—frontend hooks silently break.Proposed Solution:
tests/batch-history-api.test.tsseeding jobs via job-store helpers and asserting pagination, filters, and response shape.tests/batch-events-api.test.tsusing Vitest fetch or route handler invocation, collecting streamed chunks until close.publicKeyand unknownjobId.useBatchPolling.Acceptance Criteria:
/api/batch-historytests cover pagination, status/network filters, and requiredpublicKeyvalidation./api/batch-eventstests verify SSE headers, at least one event frame, and stream close on terminal status.