🐕 Refactor ordering of attempted fetch methods#69
Conversation
| session.log.debug(`Resolved input ${input} to PMC ID: ${pmcid}`); | ||
| input = pmcid; | ||
| // We still may be able to use original DOI input, so keep both DOI and PMC | ||
| altInput = pmcid; |
There was a problem hiding this comment.
Keep track of original input too...
| result = await downloadJatsFromUrl(session, input); | ||
| } | ||
| if (!result?.data && altInput) { | ||
| result = await downloadJatsFromUrl(session, altInput); |
There was a problem hiding this comment.
... so we can resolve against both original doi and new pmc.
| } catch (error) { | ||
| session.log.debug((error as Error).message); | ||
| } | ||
| if (doi.validate(urlOrId)) { |
There was a problem hiding this comment.
This function I split up to make the doi vs pmc vs other paths clearer.
This appears to reduce some parallelism, but I don't think it actually makes much of a difference, since the original parallel functions were often failing fast based on "is doi" vs "is pmc" checks.
|
I'm still not totally happy with the order things happen in But I think this is an improvement, so I'm going to release it, and we can iterate to resolve cases where certain DOIs (for example) are unnecessarily slow or something... |
1 participant
After #67 - there was still the case where a DOI that resolved to (1) a URL that had a custom JATS resolver and (2) a PMCID with degraded JATS would prioritize (2). This was because in
jatsFetchwe were doing theDOI -> PMCconversion before even attempting any resolving, so even though the DOI resolution was in the correct order, we only ever tried to resolve it as an already-converted PMC.I think that's a pretty bad explanation... but hopefully the code changes make some sense. I'll leave comments.