Problem Statement
File processing runs as durable, asynchronous workflows (process_runs + worker), and a batch can take a long time. Today the only signal that processing finished — or that a file failed — is to open the project and look at the file status overview (#384, #428). A user who uploads a batch and walks away gets no cue when it's done, and a failed file (with its failure reason) goes unnoticed until they happen to look.
Proposed Solution
- Backend: on
process_run completion/failure (and per-file failure), record a notification for the run's initiator. Add a lightweight count/list endpoint returning the current user's unseen processing events.
- Frontend: an in-app notification surface — a badge plus a short list of recent "processing complete" / "processing failed" events, each linking to the project or failed file. Refresh by polling and reuse the sidebar "unread" pattern in
apps/frontend/components/sidebar/AppSidebar.tsx.
Acceptance Criteria
Scope / Notes
Problem Statement
File processing runs as durable, asynchronous workflows (
process_runs+ worker), and a batch can take a long time. Today the only signal that processing finished — or that a file failed — is to open the project and look at the file status overview (#384, #428). A user who uploads a batch and walks away gets no cue when it's done, and a failed file (with its failure reason) goes unnoticed until they happen to look.Proposed Solution
process_runcompletion/failure (and per-file failure), record a notification for the run's initiator. Add a lightweight count/list endpoint returning the current user's unseen processing events.apps/frontend/components/sidebar/AppSidebar.tsx.Acceptance Criteria
Scope / Notes
process_runs); no new worker concepts required.