Hi, has anyone found any bugs in oTree? (broken functionality or not matching documentation etc) I'm going to have some time to work on oTree soon so if you have found a bug, please report it to me so that I can prioritize it.

Hi Chris

That's great to hear! I don't have a bug to report, but a dependency error when trying to use alter ego from Max Grossmann with oTree. (I posted the problem here: https://www.otreehub.com/forum/1215/)

TL/DR: Is it possible to update the oTree-dependency of markupsave and uvicorn to later versions?

Locally it works fine with the latest versions, but uploading the code to Heroku returns an error.

Best regards,
Daniel

It seems live functions perform really terribly with a large number of participants. Even the simplest function like the built in chat between participants. At 100+ participant experiment the entire otree server comes to a crawl and can even hang and become unresponsive for minutes at a time.

Has this been looked into at all, do other people have similar experience with chat feature and/or live functions in general?

I've had this issue in my own experiments years ago, and recently I've been contacted for help by people who had the same issue with theirs.

I just checked: The timeout bug reported in https://www.otreehub.com/forum/424/ (clicking the “back” button or your browser grants you additional time) still exists in oTree 5.11.1.

Please find a MWE demonstrating the bug attached.

Rather a feature request than a bug report, based on https://www.otreehub.com/forum/778/:

It would be helpful in various situations to be able to advance players individually. That is, on the “Monitor” page, there should be an “Advance to next page” or even “Advance to the end” button in each table row, that is, per participant.

Ideally, an “Advance of the end” button would add an “Experiment aborted” entry to the database for the respective participant.

A situation in which I desired such a button was the following: I was conducting an online individual-decision-making experiment, so no interaction between participants. Everyone could proceed at their own pace, but participants were asked to complete the whole study in one sitting. The experiment was open for a whole day. A few participants started making decisions but then stopped and “disappeared” after several minutes. I wanted these participants *not* to not be able to re-join, say, two hours later. So I had to open their respective URLs and click through the experiment myself, until reaching the final page. Using the “Advance slowest user(s)” button was not an option in this situation because it would have moved forward the wrong participants: those who had not stated yet at all instead of those who had started and subsequently disappeared.

The same idea applies to a situation in which participants, say, still have not joined a one-hour experiment 15 minutes before the deadline: one might want to advance these overdue participants to the final page so that it becomes impossible for them to join with such a large delay.

(BTW, the “Advance slowest user(s)” button should, in my view, be color red [Bootstrap class = "btn-danger"] rather than gray, and it should first trigger an “Are you sure?” warning message before taking effect.)

LivePages seem rather buggy, waitpages as well. We've seen participants stuck on waitpages, and had to manually refresh the browser so they pick up the pace. We've not found what the exact issue is.

P.d.: I agree with @Daniel_Frey, it'd be nice if dependencies were upgraded, i.e websockets is several versions behind

Ah, another feature request: To facilitate replication, oTree should include the oTree version that was used to conduct a study in the dataset, such as

from otree import __version__

SESSION_CONFIG_DEFAULTS = dict(
    oTree_version=__version__,
)

Ideally also installed Python packages would be documented.

Thanks for the replies. Regarding the timeout issue, I don't think it's possible to get extra time by clicking the back button. Maybe on devserver but not on prodserver, which runs a timeout worker process that prevents this.

Regarding the timeout issue, I looked into this a bit further:

`otree prodserver` does *not* solve it — neither when I run oTree locally (on my Mac) nor when I run it on a server. Also the type of database used (whether SQLite or PostgreSQL) does not have an influence.

Instead, the issue is browser-dependent. It does not occur in Safari but it does occur in Chrome and in Firefox (on Mac). (I haven’t tested other browsers.)

Thanks, I tried your MWE but couldn't reproduce the issue. I tested on Windows with Chrome and FF, and on iPhone with Safari. On all of them, clicking the back button just brought me back to the current page.

Second, even if you can access the back button and see the previous page again, does the late submitted data get stored to the DB? I tried opening a link in 2 tabs and submitting it twice, and no matter what, the second submission doesn't overwrite the first. So AFAIK while it's possible to see the previous page again, it's not possible to do anything with it.

There seems to be a misunderstanding:

The very point is that clicking the “back” button reloads the *current* page. And while doing so, the server-side countdown starts again, so that a participant has about double the intended time for submitting their response.

And yes, the response is still recorded even though the initial timeout has been exceeded.

I can reproduce the issue on Chrome, Edge, and Firefox on Windows.

Thanks for the clarification but I just tried and it works as expected for me. A few seconds after the page timeout, the page is submitted by the timeout-worker process. This message is printed in the logs:

"Auto-submitting timed out page: /p/55yc9cyk/zzz_timeout_bug/MyPage2/2"

After that occurs, the data I inputted to the form was just ignored and it's not recorded in the database.

I am trying (but failing ...) to attach a screen capture to this post that illustrates the issue using Edge on Windows: Hitting the “back” button restarts the countdown (of 10 seconds), and input is still accepted after a total of more than 10 seconds.

You are right, Chris, that the time span for which input is still accepted beyond the initial timeout is just a few seconds. (When I increase the timeout to, say, 30 seconds and try to submit after a total of 50 seconds, the input is not recorded in the database.)

It may still be confusing for participants to see a countdown that does not reflect the true time span in which they are allowed to respond. And participants also do not receive any feedback that their response was not recorded.

I think I understand the steps you describe (load a page with a timeout of N seconds, then right before it expires press 'back' to get another N seconds). When I do that I can submit a value, but when i look at the 'data' tab it's not saved there, meaning it was ignored.

In fact you can submit data a few seconds late because the server allows a few extra seconds. Maybe that explains why we are observing different things. Try setting the page timeout to 20 seconds, and see if you can submit data up to 20 seconds late with this technique and get it to show up in the admin data view. I personally cannot get that to happen.

> In fact you can submit data a few seconds late because the server allows a few extra seconds. Maybe that explains why we are observing different things.

Exactly.

ok i see - we both posted the same thing simultaneously :)

Despite the limited consequences, I still think it would be good to fix this issue, for several reasons:

(1) As I already argued, it may still be confusing for participants to see a countdown that does not reflect the true time span in which they are allowed to respond. Moreover, participants also do not receive any feedback that their response was not recorded.

(2) Experiments exist in which you would like the timeout to be just a couple of seconds, such as experiments involving time pressure. In that situation, there might be an incentive for participants to circumvent the timeout in order to “buy” themselves a couple of additional seconds, potentially making the results unreliable.

(3) Maybe most importantly: If you have a wait page included and one of the participants presses the “back” button, then also all other participants are prevented from advancing, at least for a couple of seconds. (I just tested this.) This is because the participant who presses the “back” button is not advanced to the wait page when the original timeout happens but only when the “auto-submission” happens. (In that situation, also the “Monitor” tab of the admin page shows incorrect information. In the attached screenshot, the second “Round: 3 / Page name: MyPage1” entry should be “Round: 2 / Page name: MyPage2.”)

For fixing the bug, maybe the observation that behavior is different in Safari will help: When hitting the “back” button in Safari, I see the *previous* page for something between 2 and 5 seconds, and I am then advanced automatically to the current page, with the countdown *not* being reset but having the correct value.

The actual delay in (3) can be much larger. The reason is that while the participant who pressed the “back” button has already been advanced from oTree’s perspective, they are still being displayed the “current” page (as the screenshot attached to my previous post shows) and are forced to leave that page only when the prolonged timeout runs out.

I would love to see the ability to properly debug come back. Setting breakpoints and such does not work and hasn't for a long time. It is a bit unfortunate that the only way to debug currently is to use print statements.

It would also be nice to have better performance. It is currently not recommended to do an experiment with more than a couple hundred people or so at the same time, even when using live pages. This is also a bit unfortunate. But I assume this would require oTree to gain the ability to work in parallel across multiple cores.

Ah one other useful feature that I thought from time to time:

Being able to pass a list of the already supported types to the session config (number, boolea, string), e.g.

```
dict(
    name='my_session_config',
    display_name='My Session Config',
    num_demo_participants=2,
    app_sequence=['my_app_1', 'my_app_2'],
    num_apples=[1, 2, 3]
),
```

Then when creating a session, num_apple would show as a dropdown.

It would also be nice to have complete stack traces and have all errors in the terminal.

For example, right now I have a 

otree.constants.MustCopyError: Cannot modify a list that originated in your constants class. First, you must make a copy of it, e.g. mylist.copy() This is to prevent accidentally modifying the original list. 

but nowhere in the stack trace does it mention my code. I assume it is there somewhere but it got lost. It makes debugging particularly frustrating.

Also, this error is reported in the browser when creating the session, not in the terminal. I have noticed that some errors appear only in the browser, even if they are not obviously connected to the template or the front in general.

PS: OK, I've seen that this error is a bit special in the sense that it is thrown as soon as one tries to do any of a number of operations with things involving the elements of C. It would be nice to at least append the args and kwargs to the error message, I had to makethis change in the source code to allow me to figure out where was the error.

For reference, this was the issue:

player.session.vars['my_var'] = C.my_var

which I had to change to

player.session.vars['my_var'] = C.my_var.copy()