Completed HITs are greater than the number of classifications

[rogerhutchings]

There's a bug where we're getting more HITs done than we have classifications, and it's most likely caused by the recent custom queue stuff in #28

[rogerhutchings]

After some investigation, I think it's caused by a timing issue here: https://github.com/1715labs/1715labs-pfe/blob/master/app/pages/project/classify.jsx#L114

...where componentDidUpdate is being called before the subjects have been loaded into the queue, causing the crowd callback to be triggered too early. What we need to do is check that the last subject has been seen before we call this, which we can do via seen-this-session.coffee

Unfortunately, it's a little tricky to confirm that all classifications have been saved before calling the crowd callback. Classifications are loaded into a queue which is meant to run in the background - over the large numbers of subjects a volunteer classifies, it's okay to wait a bit before this finishes. We don't have that luxury, so we might need to require that the save step completes before the next subject is loaded, or the handler is called. Waiting between each subject seems a little tortuous...

[rogerhutchings]

So - the lightweight way to to check for the right time to run is actually to ensure that:

1) there are no subjects in the queue 2) there were more subjects in the queue in the last update than there are now

...which I've done in 54cfc5ca

[rogerhutchings]

@tomnott @tingard can you let me know if this comes up again? I'm leaving the issue open for now

[rogerhutchings]

Okay, we're still getting more HITs than classifications

• HITs no longer have classification IDs attached
• HITs are completing too early
• @tingard and @tomnott couldn't replicate in staging

[rogerhutchings]

created a save classification checker in f0dd451