Closed Siddharth-Gandhi closed 1 year ago
I'm not from S2 but we encountered a similar issue in the past. Note that if you go to the s2 page of 3e83... you get redirected to the s2 page of ad21.... I think this happens when S2 merge duplicates. A couple of years ago, the default behavior was just dropping the old id and returning 404 which was much worse because you couldn't get to the paper. You can easily check it it's a different id and raise an error in your app if this is the behavior you want.
Describe the bug The batch API was working fine since my last issue (#59), however there is a very weird bug where if I give some X list of paper IDs as payload to the Batch API (same problem also exists in normal S2 API), it returns Y, an entirely different list of paper IDs in return and none of the paper IDs in Y are in X. This is very weird behaviour. Note that it does not seem to be the case for most paper IDs however for some this happens.
To Reproduce
This was the original code where I ran into the issue. Run the above code once with
working_ids
and once withnon_working_ids
. You will observe that forworking_ids
the results are exactly the same papers as needed above. However, fornon_working_ids
, an entirely different set of IDs is returned.Minimal Example Asking for one paper ID, getting something else in return.
Expected behavior I would expect the API to return the same IDs as original input for all paper IDs (not like for some it works and for some it doesn't). In the case of the minimal example, input paper ID is
3e83d54c5e8dfba82638b4f75ace31505ea60ff0
but the result paper ID isad21c3cd8871347e3bdb7cb2800049f7e8a97aca
. If the paper ID doesn't exist, return some error instead of returning an entirely different paper ID.Screenshots
Additional context From the screenshot above the problem seems to be wrong mapping of some paperIDs (for some reason), perhaps because it was remapped in the past (?) and isn't updated properly (?).