Shared request specific variable between requests?

[frankcorneliusmartin]

I am not completely sure if this is a bug or expected behavior. The flask global g which lives in the application context (which should be request specific) is shared between requests in some cases. For example when I use the following:

#!/usr/bin/python
# coding: utf-8

import time

from flask import Flask, g
from flask_socketio import SocketIO

app = Flask(__name__)

@app.route('/long')
def long():
    g.var = 'long'
    time.sleep(10)
    return g.var

@app.route('/short')
def short():
    g.var = 'short'
    return g.var

socketio = SocketIO(app)

if __name__ == '__main__':
    socketio.run(app, host='0.0.0.0', port=5000, debug=True)

When I first trigger /long intermediately followed by /short the request at the long endpoint will print short, which i expected to be long.

Could anyone explain what is happening?

[bluthen]

I just tried it, I copied and pasted this. It doesn't have that behavior for me. Maybe check all your versions. Or post which versions you are using?

I was using from pip freeze

bidict==0.21.4
click==8.0.3
Flask==2.0.2
Flask-SocketIO==5.1.1
itsdangerous==2.0.1
Jinja2==3.0.2
MarkupSafe==2.0.1
python-engineio==4.3.0
python-socketio==5.4.1
Werkzeug==2.0.2

[frankcorneliusmartin]

Hi @bluthen,

Thank you for your time to test and reply to this.

Ok, i've should have tried the example with updating the versions. The issue is that we can not upgrade Flask-SocketIO version to 5 as our client library is not compatible.

Currently we are using:

bidict==0.21.2
click==7.1.1
Flask==1.1.1
Flask-SocketIO==4.2.1
itsdangerous==1.1.0
Jinja2==2.11.2
MarkupSafe==1.1.1
python-engineio==3.10.0
python-socketio==4.4.0
Werkzeug==1.0.1

The real issue we are facing is on the production environment where this also happens (without debug=True), although i am not able to reproduce that consistently yet.

[bluthen]

So with those deps you got, running it on your system you are able to replicate everytime or often? Or does it do it one out of 100 times? Or you've never been able to replicate it, it is just you think your production environment is doing it and not sure how to replicate it there either?

You only see this happen when you include flask socketio, not just with regular flask?

I tried with your list of deps and it behaves correctly for me, but maybe I'm still missing something.

[frankcorneliusmartin]

What we observe in production

1. Our /long endpoint is reached which takes a few seconds to complete
2. Our /short endpoint is reached before the long endpoint is finished. This is already unexpected because our server is configured to only handle a single request at the time(!)
3. The long endpoint finishes, but with the parameters from the short endpoint

This every now and then, I would say 1/50 times. But ofc., only happens if concurring requests take place. This led is to investigate a little bit further. This is when we setup the example from above, and encountered that when we set the flag debug=True that we actually could send concurring requests and that the flask global was shared between these two requests.

Interesting enough, when i use a different machine I am also not able to reproduce this behavior of my example either. Ill investigate what the difference is in setup.

Edit after 5 minutes: I am also not able to reproduce it on the original machine. At this moment I start doubting everything I've seen in my live..

Thanks again for your time. It seems like the issue i raised does not exist.

[bluthen]

Edit after 5 minutes: I am also not able to reproduce it on the original machine. At this moment I start doubting everything I've seen in my live..

Just in case, maybe you can use a lock if it is suppose to handle one request at a time anyway. Sometimes it can be really hard to figure out what the cause is because it is easy to put in a work around even though you don't know why it does it.

Good luck!