[anna-parker]

When updating the revised sequence with results of the last version we set status to SUBMITTED - it should actually stay the same as the last version status (i.e. WAITING) to ensure if last version is still WAITING the newest version will continue to poll for the assembly accessions (otherwise we will have to update this manually when we get notified that not all accessions exist)

resolves #

Screenshot

PR Checklist

• All necessary documentation has been adapted.
• The implemented feature is covered by appropriate, automated tests.
• Any manual testing that has been done is documented (i.e. what exactly was tested?)

🚀 Preview: Add preview label to enable

[claude]

Claude finished @anna-parker's task in 55s —— View job

---

Review

• Read the diff and the surrounding code (assembly_table_create, assembly_table_update, submission_table_start)
• Checked which statuses the previous version can be in
• Posted review

Summary: The fix is correct for the bug it targets. Before, if the previous version was still WAITING (it had an ERZ number but no GCA or INSDC accessions yet), the unchanged revision was copied as SUBMITTED with a partial result. It then never polled ENA again, so it never got the final accessions. Copying the previous status means the new row stays WAITING, and assembly_table_update picks it up and polls the same erz_accession.

Main concern (see the inline comment): The status is now copied no matter what it is. When this code runs, the previous version may still be in SUBMITTING or HAS_ERRORS:

• With SUBMITTING, the new row is stuck in SUBMITTING forever.
• With HAS_ERRORS, the new row is marked as an error but has no error message.

I suggest only copying when the previous status is SUBMITTED or WAITING. Otherwise, return early and leave the row in READY so a later loop retries it. (In the inline comment, the code block after the "e.g." is the proposed change. The suggestion block above it just repeats the current line and can be ignored.)

Minor:

• Both versions in WAITING means ENA is polled twice for the same ERZ. This is cheap and fine.
• There is no test where version 1 is still WAITING when the unchanged revision is processed. It's worth adding one, since this is the exact case being fixed.
• The raw reads version (create_raw_reads.py:367) still hard-codes SUBMITTED. That's probably fine because raw reads have no WAITING state.

I did not run the tests.