I wanted to check in on the status of request 592018 raised by PubFactory with Crossref. The request is about an error whereby only part of the XML for a given DOI is being transferred. This problem is meaning that we are needing to register all journal DOIs manually at Bristol University Press and I believe that it is also impacting other PubFactory clients. I’ve checked in with our Project Manager at PubFactory and she says that they can’t take the ticket further until they’ve received some additional information from Crossref.
Is there any information that I can provide to help get this ticket moving?
Can you provide any update on request 592018? It is still causing a lot of manual work on our end so I’d been keen to know how it is going.
If there won’t be a fix for this soon then we will need to start looking into alternative means of bulk DOI registration, that work outside of PubFactory’s management portal.
Thanks for following up on this. Dima on our technical team investigated this last week. His review is pointing to a problem upstream of Crossref. Here’s our thinking on that right now:
First off, we have no other members, platforms, or helper tools reporting this error. Secondly, the files that we are receiving that are triggering this error are all the same size - 1,639,259 bytes - suggesting that the XML metadata files are already truncated when we receive the requests for processing.
I’ve shared this with our contacts at The Sheridan Group and they’re investigating on their end.
Are you only triggering errors on a specific role or prefix, Enzo? Or, is this error being produced for all automated BUP submissions through PubFactory?
Apologies for the delay in getting back to this. We are only seeing these failures for journal content but books seem fine. All of our journals use the prefix 10.1332 so that is the only prefix that has been affected. I will go back to PubFactory and ask them to take another look.