Re: Why would participants be waiting for other players who are still on the consent page?

[Vic vP]

This sounds somewhat similar to an issue I had before oTree lite. Participants also got stuck on waiting pages at that time. However, oTree Lite fixed that problem.

Does this problem occur only on Heroku or also when you test your app locally? Can you reproduce it locally?

On Saturday, 12 June 2021 at 19:21:58 UTC+2 Ebenezer Yakbain wrote:

Related follow-up: Essentially every participant in my study last night got stuck on a waiting page at some point (even though their partner was on the same waiting page). The solution, for many players, was to simply refresh the webpage. Several participants, however, were afraid that refreshing the page would cause a problem, so they never progressed passed the wait page. 

In general, what would cause participants to get stuck on the same wait page, without the server auto-advancing them? As an administrator, what can I do to prevent this from happening? Is it a dyno-related problem? 

On Friday, June 11, 2021 at 4:24:41 PM UTC-4 Ebenezer Yakbain wrote:

This is now the fourth time I've had the same problem happen, so it's not an anomaly.  I've attached a screenshot which shows two players waiting on other players who are currently on pages that have no "grouping" function.

One of them is a consent page (single player) and a baseline intake form (single player). Why would oTree be 'pairing' these players up with these other players? 

[Max R. P. Grossmann]

This sounds somewhat like an issue I had a while back: https://groups.google.com/g/otree/c/2zeKeWbcgG8/m/PSgGq7pWBAAJ

However, it turned out to be an issue with the reverse proxy (nginx) configuration…

Best,

Max


On 21/06/15 01:16pm, Ebenezer Yakbain wrote:
> I just recreated the issue doing the following steps:
>
>
> 1. Create a session with 4 participants
> 2. Have one participant stop at the very first app (consent form)
> 3. Have two other participants start the game and get paired up with
> each other.
> 4. One of the participants in the dyad should proceed as usual, but the
> other should stay on a page until the page expires (and they're
> auto-forwarded due to timeout_seconds).
> 5. The two players will then no longer be paired with each other. See
> attachment
>
>
> Does *anybody* have any thoughts on what might be causing this and/or how
> to solve it?
>
>
>
> On Tuesday, June 15, 2021 at 3:33:54 PM UTC-4 Ebenezer Yakbain wrote:
>
> > I cannot reproduce it locally -- it only happens on Heroku.
> >
> > I've attached another screenshot of this happening again. It seems it's
> > always triggered when somebody goes to the Consent page, and then never
> > consents (so leaves the game). The next two people who enter will get
> > paired with each other (which is supposed to happen) and then after moving
> > through an intake form and a few other phases, they are mysteriously
> > unpaired with each other. One of them will be paired with the guy waiting
> > in the consent form, and the other will be paired with the *next *participant
> > who hasn't even entered the session yet.
> >
> > I can't imagine how this is possible since the consent form has no wait
> > page... there's no pairing method on that app. I attached another
> > screenshot.
> >
> > Do you have any suggestions? I'm at my wit's end, and can't even think
> > about how to diagnose the problem.

> --
> You received this message because you are subscribed to the Google Groups "oTree help & discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to otree+un...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/otree/305ec61e-2af9-4889-86a0-7d93a40a47dbn%40googlegroups.com.

[Chris @ oTree]

Hi, I saw the app you sent me, and far as I can see, everything is working normally. The issue is that there are 3 apps (1 consent app then 2 multiplayer apps). You used group_by_arrival_time on the first multiplayer app, but not on the second, which is where the players are getting stuck. (The second app is just using the default groups from when the session was created.)

None of oTree's grouping functions (group_by_arrival_time, set_group_matrix, etc) affect the groups in other apps. For example if a 2-player game is followed by a 3-player game or a non-grouping game, it wouldn't be right to copy over the same group structure.

You can use group_by_arrival_time_method to keep the same groups as a previous app. I have added an example here: https://www.otreehub.com/projects/otree-snippets/ called gbat_same_groups.

On Tuesday, June 15, 2021 at 2:27:20 PM UTC-6 Ebenezer Yakbain wrote:

Thanks, Max. I'm not sure I have the same problem since I was just able to recreate it locally, so it can't be an issue involving server configuration / heroku. 

[Chris @ oTree]

On Thursday, June 24, 2021 at 12:38:37 PM UTC-6 Ebenezer Yakbain wrote:

Thanks Chris!

Two questions:

(1) Is this a new change in oTree? One year ago I used the exact same code (where I grouped by arrival time in only the first app) and the group structure was preserved across apps (tested successfully with 1200 participants!)

Hi, I don't know why it would have worked a year ago (I didn't change the design), but you could try that again by installing that same version of oTree again and double check.

a​

[Julien Grijalva]

Was there any solution to players having to refresh to progress past a wait page?