memphis-iis / mofacts

8 stars 1 forks source link

Lockout unit doesn't work #1404

Closed Wei940127 closed 9 months ago

Wei940127 commented 9 months ago

The Lockout unit doesn't work when participants close the page after finishing the Part 1 section and return back. Screenshot 2024-02-19 125056

Also the "unitinstuctions" following the "turkemail" did not show at the end of the Part 1 section. "turkemailsubject": "Link for 3$ Bonus for Turk HIT", "turkemail": "\r\nDear Amazon Turk Worker,\r\n", "unitinstructions":"<p><strong>Congratulations on completing Part 1 of the experiment!</strong> <br /><br /> To ensure that your assignment is approved and you receive the $5.00 payment, please enter the code <strong>'PAIRWUI'</strong> into the Amazon Mechanical Turk website for this HIT and submit your response now. ", "unitname": "Lockout unit", "deliveryparams": [ { "lockoutminutes": "1440" } ] }, Here is the package used for testing. LMRT3lockout.zip

imrryr commented 9 months ago

Should we make 2 issues? Since the instruction not showing is different than the email not going out?

JRustyHaner commented 9 months ago

@imrryr I would. I'm going to try to get to these today, I've been bogged down with meetings.

JRustyHaner commented 9 months ago

@imrryr this is addressed in PR #1407

Wei940127 commented 9 months ago

The lockout only works when the participant keeps the page open, once they log out and log in again using their ID, the timer resets from the beginning. Screenshot 2024-02-28 100620 Please see the below image, I used the same ID, and after logging in using the experiment link, the timer resets from the beginning. Screenshot 2024-02-28 100721 lockouttest.zip

Wei940127 commented 9 months ago

I tested it and this seems not working. The issue is that if the participant logs out before the timer finishes, and then logs in again, the timer resets. So the participant must keep the page open until the timer finishes if they want to start Session 2.

JRustyHaner commented 9 months ago

@Wei940127 We tested this case earlier this week, so it looks like we may need more information, since as of last deployment, we cannot reproduce it.

As silly as it may seem could you post screenshots with the JavaScript console open of the timer before logging out and after logging out and back in.

Wei940127 commented 9 months ago

Here is the screenshot at the beginning. Screenshot 2024-03-03 104401 This is the screenshot before logging out. Screenshot 2024-03-03 104505 And the screenshot after logging out and back in. Screenshot 2024-03-03 104605

imrryr commented 9 months ago

I assume you waited more than 2 minutes before resuming Wei.

So it appears to create the bug. Are you testing with a root file Rusty? That adds complexity to resuming, I imagine. Also Rusty, did you close the browser when you tested this previously. It needs to resume after the user has been gone many days, which requires the start time for the timer to be in the database and loaded when they come back. Currently, it appears to not save or load the prior time from the database.

Sorry if this was all obvious @James Haner @.***>

On Sun, Mar 3, 2024 at 10:49 AM Wei Chu @.***> wrote:

Here is the screenshot at the beginning. Screenshot.2024-03-03.104401.png (view on web) https://github.com/memphis-iis/mofacts/assets/54991536/428c3aed-d407-4a90-8a65-c09c0900b886 This is the screenshot before logging out. Screenshot.2024-03-03.104505.png (view on web) https://github.com/memphis-iis/mofacts/assets/54991536/2cee4086-d8a4-4ecd-bba9-4a69206b75e0 And the screenshot after logging out and back in. Screenshot.2024-03-03.104605.png (view on web) https://github.com/memphis-iis/mofacts/assets/54991536/1f6bf0ad-d5fa-40c8-a76e-814b4b015633

— Reply to this email directly, view it on GitHub https://github.com/memphis-iis/mofacts/issues/1404#issuecomment-1975227769, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDLPK7D6BHHJBMDRMVHXKDYWNICBAVCNFSM6AAAAABDP5XQKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZVGIZDONZWHE . You are receiving this because you were mentioned.Message ID: @.***>

-- Philip I. Pavlik Jr. @.*** http://optimallearning.org/

Wei940127 commented 9 months ago

No, this issue only happens before the timer finishes, if the participant quits in the middle of the timer counting down, and logs in again, the reset issue happens. I tried to wait more than 2 minutes to let the timer finish, in this case, after logging out and back in again, the procedure started from Session 2 directly.

imrryr commented 9 months ago

Ahhhh... that is very different. You are saying if they log in early, it resets incorrectly (it should show the time remaining). However, if they log in after it expires, it works? Please confirm.

On Sun, Mar 3, 2024 at 11:21 AM Wei Chu @.***> wrote:

No, this issue only happens before the timer finishes, if the participant quits in the middle of the timer counting down, and logs in again, the reset issue happens. I tried to wait more than 2 minutes to let the timer finish, in this case, after logging out and back in again, the procedure started from Session 2 directly.

— Reply to this email directly, view it on GitHub https://github.com/memphis-iis/mofacts/issues/1404#issuecomment-1975235672, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDLPK4K7MNXADCAGLVPBOLYWNLZ5AVCNFSM6AAAAABDP5XQKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZVGIZTKNRXGI . You are receiving this because you were mentioned.Message ID: @.***>

-- Philip I. Pavlik Jr. @.*** http://optimallearning.org/

Wei940127 commented 9 months ago

When they log out after the timer expires, and then log in again, the timer doesn't reset. In other words, the 3-day condition requires our participants to keep the experiment page open and stay logged in for 3 days, anytime they log out before the timer expires, the timer will reset when they log in again.

imrryr commented 9 months ago

OK, when you said it happens "only before the timer finishes," I misunderstood that it works after it finishes, even when logged out.

But I'm still a little confused by logout. Do they need to logout to break it, or will just closing the browser do break it. Normally people wouldn't be login out, so I assume you mean this happens after closing the browser when the timer is still running?

Wei940127 commented 9 months ago

Yes, it happens when they close the browser when the timer is still running.

Wei940127 commented 9 months ago

I just tried it again. So I closed the browser when the timer was 1min, 40s, then logged in again immediately (took about 10 seconds), and the timer started from 2 minutes. But if I closed the browser when the timer was 1min, 40s, and waited for 2 minutes, then logged in again the timer was finished and the procedure started from session 2.

imrryr commented 9 months ago

Wait, this is what I thought previously, but you said no, I thought.

So it is only broken when the student returns early? Have we concluded that now? It works if the timer is allowed to pass the 2 minutes before returning? Please answer each of these questions individually with a yes or no. ( I expect yes, yes, yes or I don't get it yet.)

Wei940127 commented 9 months ago

Yes for all three questions.

imrryr commented 9 months ago

OK, this is probably why @JRustyHaner couldn't reproduce the bug. The problem is when the student returns early, which resets the timer, but he likely checked if it worked when the timer was past.

JRustyHaner commented 9 months ago

@imrryr Another race condition. The first time the page is rendered, Meteor hasn't had time to get the current user's existing lockout timers as a response from the server side code, so it assumed there wasn't an existing one and reset the timer.

In the fix, we await the setting of the timer, so the client has to get a response before continuing.

MegaGeese commented 9 months ago

Another note. We round the lockout time up to the nearest minute when reloading. This might explain why it feels like the lockout it 'resetting'

imrryr commented 9 months ago

Ahhh, can we not do that? There is no clear reason to, so it seems like a minor bug.

On Mon, Mar 4, 2024 at 9:58 AM August White @.***> wrote:

Another note. We round the lockout time up to the nearest minute when reloading. This might explain why it feels like the lockout it 'resetting'

— Reply to this email directly, view it on GitHub https://github.com/memphis-iis/mofacts/issues/1404#issuecomment-1976911827, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDLPK6HMXIB72O7E4USQ53YWSK3RAVCNFSM6AAAAABDP5XQKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZWHEYTCOBSG4 . You are receiving this because you were mentioned.Message ID: @.***>

-- Philip I. Pavlik Jr. @.*** http://optimallearning.org/

JRustyHaner commented 9 months ago

@imrryr yep, we can do that. Making it round up didn't make much sense to me either.