Skip to content

BLAST Submit 422 Diagnostics

Motivation

Dashboard BLAST submissions could fail with HTTP 422 after the pre-flight check passed. The failing requests were hard to diagnose from the default inspector view because the visible table was dominated by successful polling requests unless the operator filtered for 4xx responses or opened the older request rows.

User-facing Change

The submit endpoint now accepts the dashboard payload shape (aks_cluster_name, db, inline query_data) and normalises it to the Celery BLAST submit contract. Inline FASTA query text is uploaded through the API sidecar into the queries container before queuing the job.

Pre-flight now sends the same sharding options and selected database metadata that submit uses, so precise-sharding blockers surface during readiness checks instead of only at final submit time.

Structured API errors now appear in the toast message for HTTP 400 / 409 / 422 / 503 cases, so submit failures show the backend reason instead of only HTTP 422.

API / IaC Diff Summary

  • /api/blast/submit and /api/blast/jobs merge submit-related top-level fields into options, including query_count, shard_sets, and DB statistics.
  • Dashboard inline FASTA payloads are materialised as queries/uploads/<job_id>/query.fa before task enqueue.
  • Submit responses include both id and job_id for frontend navigation compatibility.
  • The SPA API error formatter now reads {message}, {detail: {message}}, and FastAPI validation arrays.
  • No IaC changes.

Validation Evidence

  • uv run pytest -q api/tests/test_smoke.py -k 'blast_submit_merges_top_level_precision_metadata or canonical_dashboard_submit_uploads_inline_query or blast_submit_allows_mixed_precise_split_parent_queue' — 3 passed.
  • uv run pytest -q api/tests/test_smoke.py — 43 passed.
  • cd web && npm run build — TypeScript build and Vite production build passed.