fix(batches): results survive input-file deletion, 410 once output/error files are deleted

[pjb157]

Summary

GET /ai/v1/batches/{batch_id}/results mishandled deleted files in two directions.

Input file deleted → was a 500, now served. Deleting an input file intentionally keeps the batch but unlinks it (file_id = NULL) and lets the orphan-purge daemon remove its request templates. The results view required the file so it could walk templates in line order, and failed with Batch has no associated file_id, even though every request row is self-contained. Now:

• File present: unchanged. Walk templates in line order and join each to its request.
• File deleted: walk the batch's requests in creation order and left-join whatever template still exists (LATERAL LIMIT 1 probe, same as get_request_detail). input_body is null once the template is gone; custom_id, model, status, response_body and error are unaffected.

Search/status filters, keyset pagination and the live + archive union apply on both paths. BatchResultItem.input_body keeps its type; its doc comment now says it can be null.

Output or error file deleted → was served anyway, now 410. Those files are virtual and created with the batch, so a missing output_file_id / error_file_id can only mean the user deleted it. Deleting a results file is a statement that those results should be gone, and the endpoint used to hand back the same rows regardless. It now returns 410 Gone naming the deleted file(s), on both the paginated and streaming paths. The batch itself stays readable.

Test plan

• New test_batch_results_served_after_input_file_deleted: file_id = NULL with dangling template_ids returns 200 on /results and /results?limit=10, requests in creation order with input_body: null, completed/failed fields intact, X-Last-Line correct, ?status=failed still filters.
• New test_batch_results_gone_after_results_file_deleted: output file, error file, or both deleted returns 410 on both paths with a message naming the file; GET /batches/{id} still 200.
• Handler tests that hand-insert batches now attach virtual output/error files via a shared helper, as create_batch does. All 67 api::handlers::batches tests pass.
• test_batch_results_stream_serves_archived_batches and the template_generation_migration integration tests pass.
• cargo clippy -p fusillade-arsenal -p dwctl --tests clean for the changed code.
• .sqlx metadata updated for the changed batches lookup. Locally cargo sqlx prepare --check also flags an unrelated, untouched query file (nullability drift against my local DB); leaving that to CI's fresh database.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying control-layer with    Cloudflare Pages

Latest commit:	087f252
Status:	✅  Deploy successful!
Preview URL:	https://8b1e367b.control-layer.pages.dev
Branch Preview URL:	https://fix-batch-results-deleted-in.control-layer.pages.dev

View logs

[Copilot]

🟡 Changes recommended

The newly added 410 response message formatting includes unintended indentation whitespace due to a \-continued string literal, which should be corrected before merging.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR updates the GET /ai/v1/batches/{batch_id}/results handler to return 410 Gone when a batch’s input file has been deleted (leaving file_id = NULL), avoiding an incorrect 500 for a permanent, caller-caused state and documenting the behavior in the OpenAPI annotation.

Changes:

• Add an early batch.file_id.is_none() guard in the batch results handler that returns Error::Gone (HTTP 410) with guidance to use output_file_id / error_file_id.
• Extend the OpenAPI endpoint documentation to include a 410 response.
• Add a regression test ensuring both streaming and paginated results paths return 410 after the batch input file is deleted, while GET /batches/{id} still returns 200.

File summaries

File	Description
dwctl/src/api/handlers/batches.rs	Adds a 410 Gone handler short-circuit for missing batch file_id, updates OpenAPI responses, and adds a focused test covering the new behavior.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[pjb157]

Good catch — this was addressed by rewriting the message construction to a single-line format! string (no \\-continuation, so no embedded indentation spaces can leak into the 410 detail). We also updated the related comment in delete_file (files.rs) to accurately describe the soft-delete behavior: non-terminal batches are cancelled and unlinked, output_file_id/error_file_id are NULLed, and the file is retained for audit, so existing batch results survive file deletion.