Reload pool diminished

[VVH]

This was originally over in issue #346, but is potentially a separate issue. Whereas some people such as @CharlesDorsett are seeing some pages they have already transcribed, Mutabilitie is trying to refresh pages and load new ones without transcribing them. It's a soft skip in a way meaning the page will come back later. A number of volunteers have been doing this over the last two years and it used to work, but isn't working now. If subjects are truly served randomly, a hard refresh should get something out of your queue. The pool M is seeing is stuck at around 2-3 dozen images. I think this is possibly linked to issue #346, from what I understand of the way subjects are supposed to be served.

M writes:

"Basically, whenever I'm being shown a document that I don't fancy at the moment, I reload https://www.shakespearesworld.org/#!/transcribe/2778, which will pull a new document from the pool (I prefer that to just clicking "submit" right away, because a lot of the time I'll be happy to transcribe that page when it comes up again at a later point). Until a few months ago, this worked fine, because there were lots of documents in the pool and I would easily find a new one that I preferred after reloading two or three times. Now, though, the entire pool seems to consist of about 2-3 dozen images, which I have already seen lots of times. This means that when I reload https://www.shakespearesworld.org/#!/transcribe/2778, I will keep being shown the same 2-3 dozen images, until I flush them out of the pool, as it were by clicking "submit" (with or without transcribing a token like). I'm positive that this wasn't an issue before."

Sample subject images at issue include 53901, 53894, and 53711. These are just a few examples.

[camallen]

So in consultation with mutabilitie i've figure this out. Turns out the client caches the first call of subjects from the API and won't ask for more on a full reload of the page. Instead it takes its stored list of 10 and shuffles through them for display in the UI. This explains why the same subjects keep appearing for mutabilitie. Note: no annotations were created and the local storagesubjects were not set, {"current":null,"viewed":[]}.

I think this is an edge case of caching where we want these to persist but not across page reloads. In fact the local storage of queued subjects could probably go as some will retire behind the scenes and we may be wasting effort. Instead there should be a queue stored in a volatile variable / store that does not persist across page loads, etc.

@simoneduca i'm happy to pair on this in the new year to figure out the best way to avoid this cache issue.

[VVH]

I've found other users reporting this issue as well as of the new year, but saying they've seen the behaviour for a few months, so it affects others, too.

When you say 'Note: no annotations were created and the local storagesubjects were not set, {"current":null,"viewed":[]}.' Do you mean that the users saw the pages more than once but didn't reannotate them, or that they saw them again and may have reannotated them, but the second or third or however many annotations were not stored in the DB?

[simoneduca]

@VVH Cam and I have fixed this. Please let folks know on Talk and let us know if there are any other issues connected to this. The fix should be live shortly.

[CharlesDorsett]

Will do! Thanks for your hard work.

…

________________________________ From: Simone Duca <[email protected]> Sent: Monday, January 15, 2018 5:37 AM To: zooniverse/shakespeares_world Cc: CharlesDorsett; Mention Subject: Re: [zooniverse/shakespeares_world] Reload pool diminished (#355) @VVH<https://github.com/vvh> Cam and I have fixed this. Please let folks know on Talk and let us know if there are any other issues connected to this. The fix should be live shortly. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#355 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/Ach6ABtgPxO6EWPCo-0CXkrknB4Y-y2Xks5tK1SRgaJpZM4Q7o46>.

[VVH]

Ok, thanks @camallen and @simoneduca