[Pipeline C] Form generation: generate endpoint, fill task, retrieval endpoints (#552) - #677
Open
abhishek-8081 wants to merge 1 commit into
Conversation
marcvergees
approved these changes
Aug 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part 2 of #552 (part 1 added the Form model + migration). This builds the full form
generation flow — generate, fill, and retrieve.
What it does
A user picks the ready templates on the readiness screen and submits them. This PR takes that
request, generates a filled PDF (and a JSON version) for each template by reading values
straight from the incident's contract, and lets the user poll for progress and download the
results. No LLM runs at this stage — filling is pure lookup and draw, so a batch finishes in
seconds.
Endpoints
readiness, and splits them into queued (ready) and skipped (not ready, with a reason).
Creates a batch + one Form row per queued template, dispatches the fill task, and returns a
BatchGenerateResponse.
template_idsis required here; auto-selecting every ready templateis Batch form generation - API Contracts #554.
fly from the Form rows (no Batch table, per the agreed scope).
The fill task
For each form in the batch, independently:
resolve()fromextraction_readiness).
overlay onto the template PDF with pypdf.
the field-mapping summary (reuses
gaps_for()).Each form is wrapped in its own try/except — if one form fails, it's marked failed and the
batch carries on, so a single bad form never sinks the whole job.
Reuse and structure
Reuses
resolve()andgaps_for()from the readiness engine, and mirrors the extractionservice/worker/task split rather than the legacy fill path. Adds reportlab + Pillow.
Verification
left/center/right alignment and no vertical flip (bottom-left origin, matching ReportLab).
Three API-surface calls — implemented this way, open to your thoughts
The contract doesn't fully spell these out, so I made a call on each. They're implemented and
working as described below — happy to change any if you'd prefer a different approach:
yet returns 202 with a retry hint.
output_formatis accepted but not honored yet — the fill always writes both PDF and JSON.Honoring pdf-only / json-only felt like Batch form generation - API Contracts #554 scope.
exactly which ones), matching the per-form isolation we agreed on.