flawed logic in the new visualization timeout

Make sure these boxes are checked before submitting your issue - thank you!

• I have checked the superset logs for python stacktraces and included it here as text if any
• I have reproduced the issue with at least the latest released version of superset
• I have checked the issue tracker for the same issue and I haven’t found one similar

Superset version

0.18.5

Expected results

adhere to webserver/worker’s timeouts e.g. as per the -t flag to superset runserver, or if superset is behind a reverse-proxy to that proxy’s timeout

Actual results

adhere to hardcoded value in javascript client - 45 seconds

Steps to reproduce

superset runserver -t 300 will still show that a 60s query times out, because the timeout is set to 45 seconds in constants.js, despite 60 < 300

NOTE problem stems from https://github.com/airbnb/superset/pull/2763 which, for reasons that I cannot see nor guess, did not address the core problem: handle the 504 Gateway Time-out status code of the ajax call and instead implemented a client-side timeout / ping @graceguo-supercat

[jonathortense]

As mentioned by @graceguo-supercat, the faq says:

to change client-side timeout limit settings from /superset/superset/assets/javascripts/constants.js file and rebuild js package

Please, can anyone explain me how to “rebuild js package”? because I already changed this file and I still see the message: “Query timeout - visualization query are set to time out at 45 seconds.”

[graceguo-supercat]

If I do not run superset behind a proxy, thus hypothetically no way to get a 504 response, but having data retrieval happening in more than 45 seconds, the client-side timeout will still kick in, not allowing the users to get queries that might have ended in 50 seconds, just 5 seconds after the timeout. Is this correct (=intended) behaviour?

If I do run behind a proxy, which has a gateway timeout set to 10 seconds, the current behaviour is still to show 504 Gateway Time-out, instead of the “warning message”. Is this correct (=intended) behaviour?

If you are not behind proxy, or the proxy itself has a shorter timeout limit and you don’t want user see the 504 Gateway time-out, currently you have to change js file and rebuild js package.

Why is it that you cannot handle the 504 Gateway Time-out in a generic fashion, without having a client-side timeout?

This article might be helpful. I have limited control on proxy server.

As it is now, the current behaviour introduced a warning message, which hides a perfectly fine HTTP error message (I believe other HTTP errors are still displayed), with a magic constant, that can only be configured by monkey-patching code. Where is the improvement?

Client-side timeout limit is just a quick fix. Ideally I am thinking we should provide a configuration webpage for admin user, so that he can easily configurate instead of hard-code it. If this feature has a good amount of request, I am happy to implement it. Also I am open to any suggestion to resolve this issue.