Submissions Dashboard

The Submissions Dashboard at /submissions is the facility-admin view of every ENA submission attempt the install has ever made. It complements Submitting to ENA, which describes how a single submission flows; this page describes the dashboard you watch the queue from.

Researchers cannot reach this page — they are redirected to /orders if they try. It’s a facility-admin tool.

Layout

The dashboard is a single table titled Archive Queue with one row per Submission record. Each row collapses to a summary line and expands to a full timeline.

Top bar

Control	Behavior
Search box	Filters by entity name, accession number, or submission id
Status filter	`PENDING`, `SUBMITTED`, `PARTIAL`, `ACCEPTED`, `REJECTED`, `ERROR`, `CANCELLED`
Type filter	Limit to `study` or `sample` submissions

Row summary

Each collapsed row shows:

Column	Source
Entity	Study title or sample name (resolved from `entityType` + `entityId`)
Status	Current `status` field, color-coded
Accessions	Concatenated values from `accessionNumbers` JSON map
Date	`updatedAt`

Expanded row

Clicking a row expands it to show:

Registration steps — a vertical timeline reconstructed from response.steps[]. Each step has a name (Validation, Generate XML, Send to ENA, Parse Response, Update Database), a status (completed / error), a timestamp, and any details ENA returned.
Accession numbers — every entry in accessionNumbers, with deep links into the ENA browser when applicable (PRJEB..., ERS..., SAMEA...).
Generated XML — the exact XML SeqDesk sent to ENA, useful when ENA rejects a submission and you need to inspect what shipped.
Actions — Retry (re-runs the submission against ENA, reusing the existing record) and Delete (removes the record; idempotent — does not call ENA).

Submission states

Every submission lives in one of seven states. Transitions are deterministic and visible in the timeline.

State	Set when	Next states
`PENDING`	Just created, validation hasn’t completed	`SUBMITTED`, `ERROR`, `CANCELLED`
`SUBMITTED`	XML accepted by ENA’s intake (sync receipt)	`ACCEPTED`, `PARTIAL`, `REJECTED`, `ERROR`
`PARTIAL`	Some records inside the XML accepted, others rejected	`ACCEPTED` (after retry), `REJECTED`
`ACCEPTED`	Every record has an accession	terminal
`REJECTED`	ENA rejected every record (validation, schema, duplicates)	`SUBMITTED` (after retry), terminal
`ERROR`	Internal error before/after the ENA call (network, parser, DB)	retryable
`CANCELLED`	Operator cancelled while pending	terminal

Test-mode expiry

ENA’s test server (wwwdev.ebi.ac.uk) drops accession numbers after 24 hours. The dashboard reflects this:

Test submissions display an “Expires in Xh” countdown next to the status badge.
After expiry, the accession number stays visible but is rendered as struck through, so the row is still searchable but obviously stale.
The dashboard does not call ENA to verify; the countdown is purely client-side derived from the updatedAt timestamp.

To clear stale test submissions, use the Delete action — they will not clean themselves up automatically.

Retry semantics

Retry re-runs the same submission against the same ENA endpoint. Behavior depends on the current state:

ERROR, REJECTED, PARTIAL — full retry. SeqDesk regenerates XML (so any database fixes since the last attempt take effect), POSTs to ENA, and updates the same Submission row.
SUBMITTED — re-poll. Don’t resend; just re-parse the receipt.
PENDING — kicks the validation step. Useful if the worker died.

ACCEPTED rows have no retry button — there’s nothing to do.

Submission record

Defined at prisma/schema.prisma:

Field	Type	Purpose
`id`	cuid	Submission identifier
`submissionType`	string	`STUDY`, `SAMPLE`, `READ`, `ASSEMBLY`, `BIN`
`status`	string	One of the seven states above; default `PENDING`
`xmlContent`	string	The XML SeqDesk built and sent (kept for debugging)
`response`	JSON	ENA response plus a `steps[]` timeline that the dashboard renders
`accessionNumbers`	JSON map	Returned accessions, e.g. `{ "studyAccession": "PRJEB12345" }`
`entityType`	string	`study` or `sample`
`entityId`	string	FK into the Study or Sample table
`createdAt` / `updatedAt`	datetime	Standard timestamps

API

The dashboard reads from GET /api/admin/submissions and writes via POST /api/admin/submissions/[id]/retry and POST /api/admin/submissions/[id] for delete. Both are facility-admin-only.

When to use it

Day-to-day operations — the place to see what’s queued, what’s failed, what’s in flight.
Post-mortem on rejected submissions — expand the row, read the XML, read ENA’s response, fix the underlying record, retry.
Periodic test-mode cleanup — sort by status, filter to ACCEPTED test submissions older than 24 hours, delete in bulk.