Superset Visualizations are timing out after 60 seconds. Want to increase that. How can I implement it?

[sachitperi]

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

Expected results

Actual results

Steps to reproduce

[sachitperi]

Hi All,
My visualizations are timing out after 60 seconds with an error message "Unexpected error." The query that supports the visualization runs for roughly 2-3 min. This is a complex join query. I want to increase the timeout settings of the visualizations. I tried setting the SUPERSET_WEBSERVER_TIMEOUT to 300 also changed the settings of the gunicorn aswell. @mistercrunch Please let me know how can I do that.

[qin4zhang]

In superset config.py, you can set SUPERSET_WEBSERVER_TIMEOUT,or when you do superset runserver -t 120.Try it.

[sachitperi]

@qin4zhang
As mentioned in my comment I tried increasing the SUPERSET_WEBSERVER_TIMEOUT to 300 but nothing changed. Also the superset runserver -t didnot work

[CoryChaplin]

+1 on this issue, same problem here. Long queries run well in the SQL lab but not in graph views.
According to @abhioncbr on Gitter, il looks like the queries are not run in async mode from the graphs while they are from SQL lab.
In that case it would be a bug.
The user experience is quite blocking when using tools like Hive that often take more than the default 50 seconds.

[CoryChaplin]

@abhioncbr could the issue be related to this line ? https://github.com/apache/incubator-superset/blob/a1d867cf2f3e519c454cd33d60b9772f9c7551e2/superset/assets/src/chart/Chart.jsx#L179

I see @mistercrunch adjusted the loader rendering recently aed774e , and I have the impression that "50" is a hard coded timeout that should come from the config

[MaheshYadavalli]

I'm currently using Superset 0.28.1 and have the same issue.

[MaheshYadavalli]

I'm currently using Superset 0.28.1 and have the same issue.

This can be solved in making changes to file chartAction.js.html

export <span class="fstat-no" title="function not covered" >function runAnnotationQuery(annotation, <span class="cstat-no" title="statement not covered" >timeout = 60, <span class="cstat-no" title="statement not covered" >formData = null, <span class="cstat-no" title="statement not covered" >key) {</span></span></span></span>

[mistercrunch]

You can increase the timeout, but ultimately the "explore view" and dashboard view are meant to be somewhat interactive and the "less than a few minutes" time frame is ok for those use cases. If the query takes more than that, say 5-15 minutes, it's pretty clear that it's either too big of a workload, or simply the wrong database engine to power data exploration or dashboarding use cases. For the Hive use-case, it'd be reasonable perhaps use Hive in a data pipeline to prepare/summarize the data further and load it in a more interactive database, or use Presto. The timeout setup, from an administrative standpoint, prevents users from shooting themselves in the foot.

You'll have to make sure any proxy or load balancer in front of Superset (if any) has longer timeouts setup than Superset itself. Typically web requests are expected to timeout in the 30-120 seconds time frame.

[mistercrunch]

@CoryChaplin the <Loading size={}> refers to the image size of the loading spinner, totally unrelated.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jonberthet]

Has there been any new developments resolving the 'unexpected error' when a query runtime runs for too long?

[jackyq2015]

IMHO, most of the real world query for analytics will be running 60 sec+. How can the cap even exists?

[saurabh1-singh]

@swamy16 did you find how to extend the timeout?

[amitmiran137]

SUPERSET_WEBSERVER_TIMEOUT =300 works for me

[imamaigein99]

I increased SUPERSET_WEBSERVER_TIMEOUT to 300 and i am still getting the below Error.

We’re having trouble loading this visualization. Queries are set to timeout after 60 seconds.

This may be triggered by:
Issue 1000 - The dataset is too large to query.
Issue 1001 - The database is under an unusual load.

[moksh-enf]

In addition, has anyone deployed superset on docker? I would like to increase the timeout there as well.
Thanks!

[aastafiev]

setting SUPERSET_WEBSERVER_TIMEOUT won't work

[ShashankSetty-ByjusAcc]

any updates on this? did anyone manage to fix it?

[LeoDiep]

+1 here

[moksh-enf]

You could try adding SUPERSET_WEBSERVER_TIMEOUT=300 in the .env and .env-non-dev files for docker and re-deploying Superset.
Do let me know if that works
Thanks

[LeoDiep]

Here is what I did to solve this error on Superset v2.1 docker-compose
Step1: SSH to VM and cd to folder superset docker .../superset/docker/pythonpath_dev/superset_config.py
Add this config into superset_config.py : SUPERSET_WEBSERVER_TIMEOUT = int(timedelta(minutes=5).total_seconds())

Step2: cd to .../superset/docker and download file run-server.sh and edit as follow:
--timeout ${GUNICORN_TIMEOUT:-300} \
Then upload replace original file and restart system.

[asayeb]

I have slightly different but i believe in the same category issue. I have set the following values:
SUPERSET_WEBSERVER_TIMEOUT = 120
SQLLAB_TIMEOUT = 120
under configOverrides extend_timeout. However after hitting 59 seconds the query editor shows Database Error, Unknown Error. I just realized refreshing the page will show that the query is still running and it goes beyond 120 seconds. This could be because of default 6 hours from async query running by celery (but not sure).
I am running superset 2.0.1
anyone having this issue?!

Thanks

[hxy317]

以下是我在 Superset v2.1 docker-compose 上解决此错误的方法 ： SSH 到 VM 并 cd 到文件夹 superset docker .../superset/docker/pythonpath_dev/superset_config.py 将此 配置添加到 superset_config.py 中： SUPERSET_WEBSERVER_TIMEOUT = int(timedelta(分钟=5).total_seconds())

Step2: cd 到 .../superset/docker 并下载文件**run-server.sh**并编辑如下： --timeout ${GUNICORN_TIMEOUT:-300} \ 然后上传替换原始文件并重新启动系统。

if version is 1.x you will not find run-server.sh try edit .../superset/docker/docker-entrypoint.sh

[LeoDiep]

以下是我在 Superset v2.1 docker-compose 上解决此错误的方法 ： SSH 到 VM 并 cd 到文件夹 superset docker .../superset/docker/pythonpath_dev/superset_config.py 将此 配置添加到 superset_config.py 中： SUPERSET_WEBSERVER_TIMEOUT = int(timedelta(分钟=5).total_seconds())
Step2: cd 到 .../superset/docker 并下载文件**run-server.sh**并编辑如下： --timeout ${GUNICORN_TIMEOUT:-300} \ 然后上传替换原始文件并重新启动系统。

if version is 1.x you will not find run-server.sh try edit .../superset/docker/docker-entrypoint.sh

I was using docker version 2.5 and actually my reply above didn't work. edit /superset/docker/run-server.sh won't work. I had to go inside the container of superset_app and modified it as follow

sudo docker exec -it -u root superset_cache bash (access Superset cache container as root user)
vi /usr/bin/run-server.sh

SERVER_WORKER_AMOUNT:-6 (Based on the specs of the instant running Superset)
SERVER_THREAD_AMOUNT:-30
GUNICONR_TIMEOUT:-300

[dothangTH]

I bumped into the same issue. I'm running v2.1 on k8s. Tried fixing as @LeoDiep mentioned above but didn't work. The visualisation still got timeout after 60 seconds. As I inspected the k8s pod running the webserver, --timeout option in the gunicorn execution command was set to 300 as I expected.

Anyone can help me with this? TY in advance!

[LeoDiep]

I bumped into the same issue. I'm running v2.1 on k8s. Tried fixing as @LeoDiep mentioned above but didn't work. The visualisation still got timeout after 60 seconds. As I inspected the k8s pod running the webserver, --timeout option in the gunicorn execution command was set to 300 as I expected.

Anyone can help me with this? TY in advance!

Hi, did you edit the superset_config.py : SUPERSET_WEBSERVER_TIMEOUT = int(timedelta(minutes=5).total_seconds())

[moksh-enf]

I bumped into the same issue. I'm running v2.1 on k8s. Tried fixing as @LeoDiep mentioned above but didn't work. The visualisation still got timeout after 60 seconds. As I inspected the k8s pod running the webserver, --timeout option in the gunicorn execution command was set to 300 as I expected.

Anyone can help me with this? TY in advance!

You could also check the .env and .env-non-dev files and update the SUPERSET_WEBSERVER_TIMEOUT flag there

[aks1981]

Hi

I bumped into the same issue. I'm running v2.1 on k8s. Tried fixing as @LeoDiep mentioned above but didn't work. The visualisation still got timeout after 60 seconds. As I inspected the k8s pod running the webserver, --timeout option in the gunicorn execution command was set to 300 as I expected.
Anyone can help me with this? TY in advance!

Hi, did you edit the superset_config.py : SUPERSET_WEBSERVER_TIMEOUT = int(timedelta(minutes=5).total_seconds())

Is this resolved for you? We did the same change still same issue for Superset installed version 3.0.1

[aks1981]

I also bumped same issue in production. My report query is tacking more than 5 minutes and leading to timeout on dashboard. Please help me out if anyone has fix this issue.
Superset version - 3.1.1

[moksh-enf]

I also bumped same issue in production. My report query is tacking more than 5 minutes and leading to timeout on dashboard. Please help me out if anyone has fix this issue. Superset version - 3.1.1

Did you check the .env and .env-non-dev files and update the SUPERSET_WEBSERVER_TIMEOUT flag there?

[aks1981]

instead of SUPERSET_WEBSERVER_TIMEOUT = int(timedelta(minutes=5).total_seconds())
Changed with fixed value as below. Its working fine.
SUPERSET_WEBSERVER_TIMEOUT = 1200

[nehagoushal-cs]

I have set SUPERSET_WEBSERVER_TIMEOUT = 21600 (6 hours) which I assume should be enough.
But I am still getting '504 Gateway Timeout' error on all my charts after 60 seconds.

Anything else that I can try to fix this?

[Kolliderrr]

I have set SUPERSET_WEBSERVER_TIMEOUT = 21600 (6 hours) which I assume should be enough. But I am still getting '504 Gateway Timeout' error on all my charts after 60 seconds. Anything else that I can try to fix this?

Another workaround is to increase conn.timeout to DB using SQLAlchemy Engine params:

[praveenhalian]

I hope this email finds you well.
I am reaching out for assistance with an ongoing issue we are facing with our Superset deployment. We have configured various timeout settings for SQL Lab, Gunicorn, and other related parameters, but we continue to encounter a 504 Gateway Timeout (60000ms) error when performing queries through the Superset portal.
Issue Details:
Error: 504 Gateway Timeout (60000ms)
Superset Version: [insert version here]
Timeout Configuration: We have updated the following timeout values in the superset_config.py:
SQLLAB_TIMEOUT = 1800
SQLLAB_ASYNC_TIME_LIMIT_SEC = 1800
SUPERSET_WEBSERVER_TIMEOUT = 1800
SUPERSET_SQLALCHEMY_TIMEOUT = 1800
GUNICORN_TIMEOUT = 1800
Despite setting these values, the portal is still enforcing a 60-second timeout limit.
Troubleshooting Steps Taken:
Cleared Superset cache using superset init.
Restarted the Superset deployment after changes.
Ensured the environment variable FRONTEND_TIMEOUT was set correctly.
Cleared browser cache and tested in incognito mode.
Verified Nginx and Ingress timeout settings.
Checked logs for any errors related to timeouts.
Despite these steps, the timeout issue persists, and SQL queries are still getting cut off after 60 seconds.
Request:
I would appreciate your assistance in:
Confirming whether there are any additional configuration settings or steps needed to apply a 30-minute timeout effectively.
Identifying if there are any issues with how the timeout settings are being processed within the Superset environment.
Please let me know if you require any additional information or logs from my side to help diagnose and resolve this issue.
Thank you for your assistance.
@Kolliderrr

Message Ghazi Triki

[Kolliderrr]

I hope this email finds you well. I am reaching out for assistance with an ongoing issue we are facing with our Superset deployment. We have configured various timeout settings for SQL Lab, Gunicorn, and other related parameters, but we continue to encounter a 504 Gateway Timeout (60000ms) error when performing queries through the Superset portal. Issue Details: Error: 504 Gateway Timeout (60000ms) Superset Version: [insert version here] Timeout Configuration: We have updated the following timeout values in the superset_config.py: SQLLAB_TIMEOUT = 1800 SQLLAB_ASYNC_TIME_LIMIT_SEC = 1800 SUPERSET_WEBSERVER_TIMEOUT = 1800 SUPERSET_SQLALCHEMY_TIMEOUT = 1800 GUNICORN_TIMEOUT = 1800 Despite setting these values, the portal is still enforcing a 60-second timeout limit. Troubleshooting Steps Taken: Cleared Superset cache using superset init. Restarted the Superset deployment after changes. Ensured the environment variable FRONTEND_TIMEOUT was set correctly. Cleared browser cache and tested in incognito mode. Verified Nginx and Ingress timeout settings. Checked logs for any errors related to timeouts. Despite these steps, the timeout issue persists, and SQL queries are still getting cut off after 60 seconds. Request: I would appreciate your assistance in: Confirming whether there are any additional configuration settings or steps needed to apply a 30-minute timeout effectively. Identifying if there are any issues with how the timeout settings are being processed within the Superset environment. Please let me know if you require any additional information or logs from my side to help diagnose and resolve this issue. Thank you for your assistance. @Kolliderrr

Message Ghazi Triki

Can you send me an example of nginx-config?
What were the steps you followed through customizing variables? Mb restart superset - superset init?

[praveenhalian]

apiVersion: v1
data:
allow-snippet-annotations: "true"
enable-underscores-in-headers: "true"
kind: ConfigMap
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","data":{"allow-snippet-annotations":"true"},"kind":"ConfigMap","metadata":{"annotations":{},"labels":{"app.kubernetes.io/component":
"controller","app.kubernetes.io/instance":"ingress-nginx","app.kubernetes.io/managed-by":"Helm","app.kubernetes.io/name":"ingress-nginx","app.kubernetes.io/v
ersion":"1.1.0","helm.sh/chart":"ingress-nginx-4.0.10"},"name":"ingress-nginx-controller","namespace":"ingress-nginx"}}
nginx.ingress.kubernetes.io/proxy-connect-timeout: "1800"
nginx.ingress.kubernetes.io/proxy-read-timeout: "1800"
nginx.ingress.kubernetes.io/proxy-send-timeout: "1800"
creationTimestamp: "2023-12-15T07:46:47Z"
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/version: 1.1.0 @Kolliderrr