Peter Harrison

I think best to put this logic in the Recruiter, yes.

Nice job with the diagram @jessesnyder! > > We need to be able to approve the participant partway through the experiment > > What's included in this? Just `Recruiter.assign_experiment_qualifications()` >...

Thanks @jessesnyder, good idea.! Regarding 2, your proposal makes sense but it limits us in that we can't give participants additional bonuses after worker_complete is called (the bonus is finalised...

Sorry, I think I have been conflating these two terms. The plan is for us to submit and approve the assignment early, not to approve and then submit later.

I suppose this is a tricky issue, isn't it? The way the participant 'declares themselves done' is by being sent from the recruiter-exit page to an 'external submit' URL hosted...

I think the bonus table becomes relevant once you relax the constraint that bonus calculation/payment only happens once (on worker complete) and allow it to happen at arbitrary other times...

Note: This has been paused for now. Jesse has made good progress on relevant refactoring. We think we don't need to progress this further in the imminent future.

Thanks for the heads up. You say it's deprecated, which normally means that the code should still work just with warnings. However did you say that you're actually experiencing errors?

Update from @polvanrijn - the limit seems to be per email address (`contact_email_on_error`), and changing the lab's practices to use different email addresses solved the issue.

You mean, generate a random email address to circumvent their API limit?