/network/x route fails when network is a custom class: 3pt

Update & Current Plan (Jan 4th, 2020)

We suspect the problem is caused by runtime import of the experiment’s models module, following the example of the various official demos. The demos use this technique to avoid warnings from SQLAlechemy when the experiment package is imported multiple times.

Since a warning is preferable to the error reported in this issue, @thomasmorgan and others will try using a conventional, top-of-file import for models to see if this resolves the problem. If it does, we will probably return to using this import style in the demos.

Original Description

Sending a request to server/network/x causes an internal server error. This is only true for the first few seconds in debug mode, but it lasts sporadically for up to an hour when deployed/sandboxed

Expected Behavior

The route should return a json description of the network

Current Behavior

Instead of getting a json of the network, the user gets a 500 error message. The server logs show a bunch of errors, culminating in

12:41:26 PM web.1   |      "No such polymorphic_identity %r is defined" % discriminator
12:41:26 PM web.1   |  AssertionError: No such polymorphic_identity 'xxxxx' is defined

where xxxxx is the polymorphic identity of the custom network class.

Steps to Reproduce (for bugs)

1. Find an experiment with a custom network class (none of the demos use this). I have reproduced the issue in my repos here (private) and here (public).

In debug mode: 2. Start the experiment. 3. Immediately go to http://0.0.0.0:5001/network/1 4. The error should appear. For me it persists for a few seconds of refreshing before it starts working

In sandbox/live: 2. deploy the experiment 3. Go to <server address>/network/1 4. The error will appear. For me, it persists for up to an hour. Initially refreshing causes the error ~90% of the time, this steadily decreases until after an hour when the error seems to be gone entirely.

Context

This is the only route by which a participant can get a json of their network. I was using it to check whether the network was full or not.

Your Environment

• Dallinger version used: 5.1.0, 6.3.0, 6.5.0
• Operating System and version (desktop or mobile): MacOSX
• Browser and version (e.g. Chrome 39, node.js 5.4): Chrome 85

[thomasmorgan]

Where we are now:

The issue is actually about how experiment.py imports from models.py. The current style is within init:

    def __init__(self, session=None):
        super().__init__(session)
        from . import models
        self.models = models

This was adopted deliberately: It suppresses an irritating sql warning that otherwise spams the logs if the more usual (i.e. module level) methods imports is used. However, it may have introduced the error. Because errors are worse than warnings the current set up is untenable. That said, given the spam in the logs perhaps going back to module level imports is not the best.

To do:

1. Confirm that the import style is responsible for the bug.
2. If so: 2a. Revert demos back to module level importing 2b. Think about other ways to get rid of spam in logs
3. If not: 3a. Think about other possible causes of bug
4. Report back

[thomasmorgan]

@jessesnyder Interesting that you cannot replicate it, but if it is a race condition then various system properties can no doubt effect it. We encountered in a lot when live, so at least it’s not just my system!

I think your plan sounds good: revert to top-of-module importing in future experiments, note any unusual behavior or log spam, reconvene later to discuss reverting the demos/docs too.