Multiple posting of full PREreview

[dasaderi]

Some users are posting multiple full PREreviews per preprint. There should be only one full PREreview per user allowed.

E.g. https://prereview.org/preprints/doi-10.21203-rs.3.rs+420780-v1

[dasaderi]

@jheretic sorry to bug you about this, but do you know why this is happening?

[murkatr]

Also this one: https://www.prereview.org/preprints/doi-10.1101-2021.03.04.433973

[murkatr]

A reviewer said they got an error (Failed to fetch: 400 Bad Request) when trying to submit their full PREreview.

[jheretic]

Hey all, I'll take a look as soon as I can! Having a staff retreat this week but I'll look at it in the off hours and let you know!

[dasaderi]

Thank you @jheretic. We just got another similar report.

"I just wrote my first full prereview (yay!) but got a 400 error popup when I tried to submit it. I clicked again (same error) and then went to my profile and saw the review did get received and has been posted twice. Can you remove one of them please (I also clicked report on one but expected to have the option to more details)

https://prereview.org/preprints/doi-10.1101-2020.12.11.422154

[jheretic]

@dasaderi Copied from Slack: it appears that the HTTP 400 error is because it's failing to fetch a DOI from Zenodo for the review. It's not clear yet why that's failing (I'm setting up some test code to examine the review cycle to see if it's an issue on their side or ours), but as it stands that is setup to cause the review submission to be denied. That should cause it to cancel out of the request, but for some reason the review is still getting commited to the database in a way that causes the author check to be skipped. It's not clear why that's getting skipped, but the prereview submission logic is pretty complex because of all the draft and ownership checks. I'll see about making sure the ownership check isn't skipped if the DOI fetch from Zenodo fails.

[dasaderi]

@jheretic THANK YOU so much for taking the time to look into this. Do you know or have an idea of why the DOI from Zenodo may not be fetched properly? @thewilkybarkid is out on holiday this week, but he'll take a look too when he's back. Happy to pay for your hours of work Josh if you have time to fix this problem this week.

[thewilkybarkid]

Do you know or have an idea of why the DOI from Zenodo may not be fetched properly?

Since it's an external service there's always a chance that it'll be unavailable.

Reading the code in

prereview/src/backend/controllers/fullReview.js

Lines 180 to 205 in 03cb583

	await reviewModel.persistAndFlush(review);
	} catch (err) {
	log.error('HTTP 400 Error: ', err);
	ctx.throw(400, `Failed to parse full review schema: ${err}`);
	}
	let reviewData;
	// shape data for ZENODO if none of the authors are anonymous
	if (review.isPublished) {
	reviewData = {
	title: review.title || `Review of ${preprint.title}`,
	content: draft.contents,
	creators: creators,
	};
	try {
	// yay, the review gets a DOI!
	review.doi = await generateDOI(reviewData);
	} catch (err) {
	log.error(`Error generating DOI from Zenodo. ${err}`);
	ctx.throw(400, `Failed to generate DOI.`);
	}
	}
	try {
	await reviewModel.persistAndFlush(review);

the flow is:

1. Create a local review object
2. Save it
3. Send to Zenodo (actually 3 steps: create a deposition, upload the file, publish the deposition)
4. Add DOI to local review object
5. Resave it

I haven't any logs to see why step 3 failed, but there's always a chance it will.

This should be a distributed transaction (a unit of work involving multiple hosts) but isn't. Instead, each operation is its own transaction, so a failure only stops later ones from happening (rather than also rolling back earlier ones).

[thewilkybarkid]

In terms of actions:

1. Remove the ability to post multiple reviews (there's a failing test case)
2. Try and add lower-level test cases (to test what happens when Zenodo fails)
3. Change the logic so the failing cases from 2 pass

Also, what should happen with the published reviews that have no DOI? (Refs sciety/sciety#1142)

[thewilkybarkid]

I've started the (long) road to creating a failing test case for when Zenodo fails. Unfortunately, as the code is not amenable to testing it has to have a real database running (as the code depends on the ORM). This has thrown up a surprise in that the ORM is misconfigured and has unresolved migrations (as it stands, a new DB structure can't be generated from the code). I'm trying to reveal this problem in d4c18e4.

[thewilkybarkid]

The next big hurdle for testing is to make the configuration amenable (#419).

[thewilkybarkid]

I've overcome two more big hurdles on the way to creating a failing test case: having a test case interact with a database (2c6e835) and mocking HTTP requests made by the app (1e0840e).

[thewilkybarkid]

Been taking a look into duplicate reviews, and noticed that when a full review is published a new one is made rather than updating the isPublished flag (assuming it's been saved).

This partially explains why https://prereview.org/api/v2/preprints/8429c125-783e-47b2-974f-fa47863c0bd2 shows three full reviews by the same author (2 unpublished, 1 published).