Received this Crossref error message:
batch_id
apsxref:0db3c004-fda3-46cd-80ce-91302738396c
doi
10.1103/PhysRevD.110.103017
msg
Handle timestamp mismatch, deposit: 20241213162421 handle: index=700050 type=700050 rwr- “20241213162424”
submission_id
1660807780
What does this error indicate? Hiow does it differ from other timestampt errors? Trying to understand if I can ignore this error.
Hi @mklem ,
This one is also a rare error. It happens when the timestamps in our system get out of sync with the timestamp stored in the handle system. I have reset the timestamp in our system, which normally does the trick, and have re-pushed the submission - 1660807780. The DOI has now been successfully updated.
aWarm regards,
Isaac
Thanks Isaac.
How does the timestamp get out of sync? How often does this happen?
Thank you
Hi @mklem ,
While very rare, the timestamps can get out of sync because these are two systems and sometimes they have communication errors (e.g., a temporary connection issue). Like I said, they’re very rare. We typically get a couple of tickets about this every year.
Warm regards,
Isaac
Hi Isaac,
Got another timestampt mismatch error this morning:
{“batch_id”:“apsxref:51bf989d-47f5-498b-8c35-c000bc9a934b”,“doi”:“10.1103/PhysRevFluids.9.123801”,“msg”:“Handle timestamp mismatch, deposit: 20241220154133 handle: index=700050 type=700050 rwr- "20241220154134"”,“submission_id”:“1661918171”}
Can I just ignore these or resubmit the XML data when I get these errors?
Wondering if there is something I can do on my end to retry in this case.
Thanks for flagging this to us @mklem. Well, this is concerning to have a couple of these errors in such close proximity. I am going to ask our technical team to take a look to see if we might have a bug or larger problem. As I said, there are typically quite rare.
I have reset your timestamp and successfully reprocessed submission https://0-doi-crossref-org.library.alliant.edu/servlet/submissionAdmin?sf=detail&submissionID=1661918171
Unfortunately, you can’t simply resubmit these to avoid the timestamp error. We first need to intervene to reset the timestamp in our system (in order to resync the two systems). That said, there may be a larger systems issue here that I have asked our technical team to investigate.
-Isaac
