deposit succeeds on sandbox, but fails on production

[jhpoelen]

For some reason, on 2026-02-25, I was able to deposit a record

https://sandbox.zenodo.org/records/446395

and, was unable to deposit that exact same record on production with the following error being reported on "publish" action

[<https://zenodo.org/api/deposit/depositions/18774556/actions/publish>] with reason [INTERNAL SERVER ERROR] and possible error message [{"error_id":"66d2544e57004d5695fb93b9b3cd5524","message":"The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.","status":500}

the file attachment and associated metadata was uploaded successfully.

The associated metadata was:

{
  "metadata": {
    "http://www.w3.org/1999/02/22-rdf-syntax-ns#type": "taxodros-dros5",
    "keywords": [
      "Biodiversity",
      "Taxonomy",
      "fruit flies",
      "flies",
      "Animalia",
      "Arthropoda",
      "Insecta",
      "Diptera"
    ],
    "custom": {
      "dwc:kingdom": [
        "Animalia"
      ],
      "dwc:phylum": [
        "Arthropoda"
      ],
      "dwc:class": [
        "Insecta"
      ],
      "dwc:order": [
        "Diptera"
      ]
    },
    "referenceId": "abdelbaki et al., 2025",
    "related_identifiers": [
      {
        "relation": "isAlternateIdentifier",
        "identifier": "urn:lsid:taxodros.uzh.ch:id:abdelbaki%20et%20al.%2C%202025"
      },
      {
        "relation": "isVariantFormOf",
        "identifier": "10.1080/00305316.2024.2447303",
        "resource_type": "publication"
      },
      {
        "relation": "isDerivedFrom",
        "identifier": "https://linker.bio/line:hash://md5/3b890c93ae2093ccaa5f5c3395494deb!/L29-L38"
      },
      {
        "relation": "isDerivedFrom",
        "identifier": "10.5281/zenodo.18764503"
      },
      {
        "relation": "isPartOf",
        "identifier": "https://www.taxodros.uzh.ch"
      },
      {
        "relation": "isPartOf",
        "identifier": "hash://md5/47cc02b56e5d21384e01ba0b7d3c170d"
      },
      {
        "relation": "isPartOf",
        "identifier": "hash://sha256/612ecde6ac7582b643a56b6ca5648c92cb122fcdf99e68c4bb0f64e9c56b5c76"
      },
      {
        "relation": "isAlternateIdentifier",
        "identifier": "hash://md5/b498aa7b5e476ce654f8f853540c2a47"
      }
    ],
    "creators": [
      {
        "name": "Abdelbaki, L."
      },
      {
        "name": "Saidi-Touati, M."
      },
      {
        "name": "Serrano, C."
      },
      {
        "name": "Yassin, A."
      },
      {
        "name": "Boutellis, A."
      }
    ],
    "access_right": "restricted",
    "publication_date": "2025",
    "title": "New haplotypes of Zaprionus tuberculatus and Zaprionus indianus (Diptera: Drosophilidae) identified in fig orchards in Algeria.",
    "publication_type": "article",
    "journal_title": "Oriental Insects",
    "journal_volume": "59",
    "journal_pages": "326-339",
    "journal_issue": "2",
    "taxodros:method": "ocr++ / DOI:10.1080/00305316.2024.2447303",
    "http://www.w3.org/ns/prov#wasDerivedFrom": "line:hash://md5/3b890c93ae2093ccaa5f5c3395494deb!/L29-L38",
    "references": [
      "Bächli, G. (2026). TaxoDros - The Database on Taxonomy of Drosophilidae hash://md5/47cc02b56e5d21384e01ba0b7d3c170d hash://sha256/612ecde6ac7582b643a56b6ca5648c92cb122fcdf99e68c4bb0f64e9c56b5c76 [Data set]. Zenodo. https://doi.org/10.5281/zenodo.18764503"
    ],
    "filename": "Abdelbaki et al., 2025.pdf",
    "upload_type": "publication",
    "communities": [
      {
        "identifier": "taxodros"
      },
      {
        "identifier": "biosyslit"
      }
    ],
    "description": "Uploaded by Plazi for TaxoDros. We do not have abstracts."
  }
}

confusingly, an earlier record with similar metadata was successfully published at

Abd El-Halim, A. S., Soliman, M. I., Aly, N. S., & Mikhail, M. W. (2009). Prevalence of dipterous flies with human and animal diseases in Menoufia Governorate, Egypt. Journal of the Egyptian Society of Parasitology, Vol.48(2), 459–461. https://doi.org/10.5281/zenodo.18774025

@slint @myrmoteras please advise on how to proceed.

[jhpoelen]

For some reason, I was able to upload some deposits with metadata and pdf via API with push to publish via website.

e.g.,

https://zenodo.org/records/18808227

[jhpoelen]

see also TaxoDros/TaxoDros.github.io#50

[slint]

Hi @jhpoelen, thanks for reporting the issue along with the error ID. I just looked into it, and this is a bug on our side related to the fact that the Taxodros community, has been setup as a "subcommunity/project" of BLR. When this is the case, submitting to the community, automatically adds it also to its "parent". This triggers a bit of a jumble, and we end up trying to insert a duplicate row in the DB, thus causing the 500 error.

So the solution would be now to remove from the communities array, the {"id": "biosyslit"} entry, and only include {"id": "taxodros"} (and on publish the record will be automatically added to BLR as well).

Let's keep this issue open, until we patch this though properly (the intended behavior should be that it succeeds even though there is a "redundant" paired parent community in the array).

[jhpoelen]

@slint thanks for your prompt reply and for looking into this. While you are working on a fix, I'll make an effort to remove the biosyslit community entry in the taxodros metadata records by patching.

[jhpoelen]

Worked great. Thanks for the tip!

[cyphernetsecurity]

Nice catch on the duplicate insert issue related to the communities array — that explains the 500 error behavior.

One thing that might be worth considering longer-term is adding validation or normalization on the API side to prevent redundant parent/child community entries from reaching the DB layer.

Right now the failure only surfaces at insert time, but catching this earlier (e.g. deduplicating or enforcing constraints before persistence) could avoid this class of issue entirely and make the API more resilient to inconsistent metadata inputs.

Especially since this seems to depend on how external metadata is structured, having a guard at the boundary could help prevent similar edge cases in the future.