Y26-108 - [Psd-exceptions] Accession::ExternalValidationError - No new objects can be added with MODIFY action

[StephenHulme]

Describe the bug
Samples are submitted via sample manifest with a pre-populated accession number that does not match the stiplulated service set in the study. This generates an exception email with the text No new objects can be added with MODIFY action

To Reproduce
Steps to reproduce the behaviour:

1. Upload a sample manifest with an accession number pre-populated, that has not been assigned by the ENA or EGA service
2. Receive a Failed accession status and exception notification email

Expected behaviour
No error should occur as this is an expected operation

Screenshots

Additional context

Explanation of study fields and how they are used: Document Study Creation Form_v2

Email content:

An Accession::ExternalValidationError occurred in background at 2026-03-08 10:30:22 +0000 :

  In sample, alias: "6c6bd324-1947-11f1-8d2b-02426899d835". No new objects can be added with MODIFY action.
  /var/www/sequencescape/releases/20260224125951/lib/http_clients/accessioning_v1_client.rb:103:in 'HTTPClients::AccessioningV1Client#raise_if_failed'

-------------------------------
Backtrace:
-------------------------------

...

-------------------------------
Data:
-------------------------------

  * data: {message:
    "SampleAccessioningJob failed for sample '7370STDY16705489': In sample, alias: \"6c6bd324-1947-11f1-8d2b-02426899d835\". No new objects can be added with MODIFY action.",
   sample_name: "7370STDY16705489",
   service_provider: "ENA",
   user: "xxnn"}

[StephenHulme]

This happens most freqently with ToL studies, as they have their own off-line accessioning system using the BioSamples database which generates SAME numbers.

Redacted conversation with Paul D from ToL below:

PSD:

Can you please outline the use-cases or scenarios where accession numbers are entered on a sample manifest for upload, and particularly why a sample might be associated with one or many BioSamples numbers as opposed to a single ENA (or EGA) number? It would be good to better understand how Sequencescape is being used and make any changes that are required for more streamlined processing of sample information.

For context, the greater visibility of sample accessioning has highlighted some cases of data-entry issues, which show up with the error No new objects can be added with MODIFY action . The primary cause of this is non ENA/EGA accession numbers (eg: SAMEA120577981) being entered into the ENA Sample Accession Number field. These often do not match the SAMEA (BioSamples) numbers that have been entered into the Donor Id or occasionally Sample Description fields of the same sample.

ToL:

ToL use the donor_id, accession number fields in a slightly different way to other programmes I guess.
As we have collaborators or our own accessioning service for samples we supply the ENA SAME accessions that we generate (or should).
For our core lab, there is a template so the data is presented to the lab member in a way that is easy to transfer to the manifest that is destined to SequenceScape. For the faculty labs this is a slightly more disjointed process.

Ah ok, so ToL uses the 2 tier biosample accessioning Hierarchy that ENA supports.

We map:
donor_id - specimen level biosample accession SAME
accession_number - sample level  biosample accession SAME(different to donor_id)

So using SAMEA120577981  as an example, this is a sample level accession which belongs to SAMEA120577878  identified by the sample derived from field

SAMEA120577878 also has 3 additional derived samples:

SAMEA120577983
SAMEA120577984
SAMEA120577985

Could you elaborate on the No new objects can be added with MODIFY action  as SAMEA120577981 should be an acceptable biosample accession number:
https://www.ebi.ac.uk/ena/browser/view/SAMEA120577981

PSD:

Thanks for the detailed explanation, that makes more sense and it does sound like the tol usage differs significantly from other programs - at least in terms of how Sequencescape expects those fields to be used.

In sequencescape, the accession_number field maps specifically to an ENA or EGA accession number and not a Biosamples accession number. This functionality allows sample metadata on ENA or EGA to be updated whenever a change is made to the sample on Sequencecsape. If a non EGA or ENA accession number is entered, it still tries to update the ENA or EGA database, leading to the error No new objects can be added with MODIFY action (essentially, the biosample accession number cannot be found in the ENA or EGA databases).

The donor_id field is considered free text, with no additional update behaviour supported.

From ToL's point of view:

1. What is the requirement to associate a sample level Biosample accession with a sample?
   a. Is this purely for record association (like in the donor-id case)?
   b. Are metadata updates to the Biosample DB expected or required?
2. Regarding the derived samples SAMEA12057798(3-5), how are these associated with the original sample SAMEA120577981 in Sequencescape, is there meant to be a traceable link?

ToL:

Ah ok, so yes we accession all our samples independently of SequenceScape so would not need/utilise this functionality of SS. (We) as broker of the sample to ENA handle all the updates as we utilise a much richer ENA checklist for storing metadata than the general Sanger list (not sure of the checklist ID).

https://www.ebi.ac.uk/ena/browser/view/ERC000053

I think the error is more down to our ENA records not being in the same webin account as the ones that SS would generate.

Answering your questions in line
From ToL’s point of view:

1. What is the requirement to associate a sample level Biosample accession with a sample?
   a. Is this purely for record association (like in the donor-id case)?
   b. Are metadata updates to the Biosample DB expected or required?

Yes, we require the donor_id to be a specimen level ENA Biosample for our downstream Assembly and QC systems as this is the primary hook to the individual specimen that is being worked on (data from multiple samples from the same specimen can be grouped together for assembly an analysis).

Accession number resolves the sample down to the individual sample from that specimen so again identifies things like the tissue type, specific preservation approaches etc. and basically connects the Sequencing outputs directly back to the collected sample and metadata.

We would not expect any metadata updates from outside of programme for our samples (unless in a study not going through the core genome engine).

2. Regarding the derived samples SAMEA12057798(3-5), how are these associated with the original sample SAMEA120577981 in Sequencescape, is there meant to be a traceable link?

We do not need any association within SS other than those imposed by study as all of this is handled within programme systems.

One thing we could do is tighten up on the accept/reject of sample manifests when they do not meet the ToL SAME accession requirements for accession_number and donor_id fields, but this might be tricky to police as some side studies don’t have this requirement, but it’s something we can explore.

PSD:

Thank you for all the detail - that's really helpful and I now have a much better idea of the use cases and constraints that you are working within.

One thing we could do is tighten up on the accept/reject of sample manifests when they do not meet the ToL SAME accession requirements for accession_number and donor_id fields, but this might be tricky to police as some side studies don’t have this requirement, but it’s something we can explore.

Yes, this would be possible to do from our side. If this was just a simple rule, it would be easier to apply, but due to the side studies you mention, I agree that more discussion would be required.

On the other end of the sequencing-data pipeline, do you know where or who extracts the accession_number field? If the name of the field were to change, would this break a lot of functionality, or could it easily be adapted?

ToL:

What would the rational be for moving the accession number out of the field it currently occupies? That seems the logical place and the accession_number attribute in the MLWH and likely iRods is baked into a lot of our and potentially other peoples systems.

I guess the only difference is that we provide the secondary SAME id instead or the ERS submission accession.

PSD:

It's the ERS we store and manage. But this is all implicitly done, so using a secondary SAME id breaks the system.

[StephenHulme]

One proposal is to untick the Enforce accession numbers box in the Manage Study page for the ToL studies. Paul will take the proposal to the rest of the ToL team and get back to us.

[StephenHulme]

Response from Paul

Update, I still need to check with one faculty member but on the whole it seems that we are fine with removing the enforce accession numbers for most of our studies. The issue of auto release was also raised and that for a lot of our studies we would also need to revise this. Faculty are also going to explore Study granularity to separate out data and have a more consistent data release for specific projects/studies.

[StephenHulme]

The accessioning updates made in #5717 and #5718 will redirect the errors that are raised so that they have more visibility for users and SSRs.

Closing for now unless there is an update.