CrossRef / rest-api-doc

Documentation for Crossref's REST API. For questions or suggestions, see https://community.crossref.org/
Other
743 stars 269 forks source link

Mysterious "internal server error" for ISSN 2620-1607 #445

Closed ifarley closed 5 years ago

ifarley commented 5 years ago

I have never seen an internal server error for a legitimate CRDMS: https://search.crossref.org/?q=2620-1607. There is something strange going on with this journal though. I get a “resource not found” error when I call: http://api.crossref.org/journals/2620-1607/works but that ISSN is connected to a few DOIs, including this one: http://api.crossref.org/works/10.31181/oresta1901001b

ppolischuk commented 5 years ago

Potentially related to #418 and CS-3596.

gorbynet commented 5 years ago

In case you need another test case, this also happens with ISSN 1479-3601. It might be causing Null Pointer Errors when attempting to deposit DOIs associated with that ISSN.

pdavis8 commented 5 years ago

I am also getting the same error message when looking for ISSN 2651-2939 as well.

pdavis8 commented 5 years ago

More examples of this behaviour:

  1. Communications in Advanced Mathematical Sciences, 2651-4001, https://dx.doi.org/10.33434/cams.
  2. Journal of Mathematical Sciences and Modelling, 2636-8692, https://dx.doi.org/10.33187/jmsm.
  3. Fundamental Journal of Mathematics and Applications, 2645-8845, https://dx.doi.org/10.33401/fujma.
MikeYalter commented 5 years ago

a few things: Pdavis: comment with the journals and dois, weirdly none of those DOIs exist. I don't think that matters to this problem though. I looked into the problem a bit, found a few things:

  1. the titleFile.csv has an extra field the indexer wasn't expecting. Fixed that in the indexer, and restarted it.
  2. fix in columns and restart did not fix the problem.
  3. looked more into the mongo db, oracle db and titleFile.csv Seems the titleFile isn't being updated. It doesn't include journals in the oracle db. The oracle db currently has about 7200 more journals in it than the mongo db. Following up with Jon/Tim to make sure the file is being updated and located in the right place.