I somehow ended up with a mismatch between the zenodo record id and the identifier in datapackage.json. Likely something went wrong when creating a new version of the deposit.
For the sake of this issue lets say id 1 and id 2
When viewed in the Zenodo dashboard and looking at the raw json, the draft record had record id 2 but the DOI from record id 1. This meant I couldn't discard the draft because the doi in the Zenodo metadata was invalid. I was able to update the DOI to the correct value and then foolishly decided to publish that version of the deposit. I did not think to look at the datapackage.json file. The identifier in the datapackage was for record 1.
So subsequent attempts to create versions of the data failed because the datapackage for record 2 had a bad doi in the datapackage. Once the identifier in the datapackage was updated for record 2, I was able to create new versions of the deposit.
Potential Solution
Add a check to deposit_retrieve that verifies the zenodo record id and datapackage identifier are equal when the host doesn't have frictionless data probably around line 823
I somehow ended up with a mismatch between the zenodo record id and the identifier in datapackage.json. Likely something went wrong when creating a new version of the deposit.
For the sake of this issue lets say id 1 and id 2
When viewed in the Zenodo dashboard and looking at the raw json, the draft record had record id 2 but the DOI from record id 1. This meant I couldn't discard the draft because the doi in the Zenodo metadata was invalid. I was able to update the DOI to the correct value and then foolishly decided to publish that version of the deposit. I did not think to look at the datapackage.json file. The identifier in the datapackage was for record 1.
So subsequent attempts to create versions of the data failed because the datapackage for record 2 had a bad doi in the datapackage. Once the identifier in the datapackage was updated for record 2, I was able to create new versions of the deposit.
Potential Solution
Add a check to
deposit_retrievethat verifies the zenodo record id and datapackage identifier are equal when the host doesn't have frictionless data probably around line 823