Metabase query timeout despite MB_DB_QUERY_TIMEOUT_MINUTES

Get Help
1

Hello fellow Metabase users,

We’re encountering an inconsistent timeout behavior with Metabase 0.53.5 connected to a self-hosted Trino cluster. Despite Trino successfully completing a ~10 minute query, Metabase aborts after just 1 minute with "Your question took too long".

Current timeout settings:
MB_DB_QUERY_TIMEOUT_MINUTES: 30
MB_JETTY_ASYNC_RESPONSE_TIMEOUT: 3600000 (60 mins)

According to the documentation, MB_DB_QUERY_TIMEOUT_MINUTES should set the database timeout, but Metabase seems to ignore this.
Has anyone encountered this discrepancy between Trino completion and Metabase timeouts?

Is there a hidden timeout setting overriding these values?
Any suggestions would be greatly appreciated!

Some additional context:

  • No reverse proxy between Metabase/Trino
  • Trino’s query.timeout is set higher than 30 mins
  • Trino Version 469
  • Driver Starburst Metabase 6.1.0
  • Metabase logs show "isClosed" at 60s mark
analytics-mb-fc466b6d-ck2t9 metabase Exception in thread "async-dispatch-9" java.lang.UnsupportedOperationException: isClosed                                                                                                             
analytics-mb-fc466b6d-ck2t9 metabase     at metabase.driver.implementation.execute.proxy$java.lang.Object$Statement$ed45fa56.isClosed(Unknown Source)                                                                                     
analytics-mb-fc466b6d-ck2t9 metabase     at metabase.driver.sql_jdbc.execute$wire_up_canceled_chan_to_cancel_Statement_BANG_$fn__85617$state_machine__62997__auto____85622$fn__85624.invoke(execute.clj:532)                              
analytics-mb-fc466b6d-ck2t9 metabase     at metabase.driver.sql_jdbc.execute$wire_up_canceled_chan_to_cancel_Statement_BANG_$fn__85617$state_machine__62997__auto____85622.invoke(execute.clj:530)                                        
analytics-mb-fc466b6d-ck2t9 metabase     at clojure.core.async.impl.ioc_macros$run_state_machine.invokeStatic(ioc_macros.clj:972)                                                                                                         
analytics-mb-fc466b6d-ck2t9 metabase     at clojure.core.async.impl.ioc_macros$run_state_machine.invoke(ioc_macros.clj:971)                                                                                                               
analytics-mb-fc466b6d-ck2t9 metabase     at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invokeStatic(ioc_macros.clj:976)                                                                                                 
analytics-mb-fc466b6d-ck2t9 metabase     at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invoke(ioc_macros.clj:974)                                                                                                       
analytics-mb-fc466b6d-ck2t9 metabase     at clojure.core.async.impl.ioc_macros$take_BANG_$fn__63015.invoke(ioc_macros.clj:985)                                                                                                            
analytics-mb-fc466b6d-ck2t9 metabase     at clojure.core.async.impl.channels.ManyToManyChannel$fn__59189$fn__59190.invoke(channels.clj:100)                                                                                               
analytics-mb-fc466b6d-ck2t9 metabase     at clojure.lang.AFn.run(AFn.java:22)                                                                                                                                                             
analytics-mb-fc466b6d-ck2t9 metabase     at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)                                                                                                                   
analytics-mb-fc466b6d-ck2t9 metabase     at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)                                                                                                                  
analytics-mb-fc466b6d-ck2t9 metabase     at clojure.core.async.impl.concurrent$counted_thread_factory$reify__44801$fn__44802.invoke(concurrent.clj:29)                                                                                    
analytics-mb-fc466b6d-ck2t9 metabase     at clojure.lang.AFn.run(AFn.java:22)                                                                                                                                                             
analytics-mb-fc466b6d-ck2t9 metabase     at java.base/java.lang.Thread.run(Unknown Source)
2

Something seems to be killing the request. You said you don't have a reverse proxy, can you share more details about how you're deploying metabase and overview of your infrastructure?

3

@TonyC Thanks for looking into this.

To add context:

Some infrastructure details

  • Metabase deployment: Metabase runs on a self-hosted RKE2 kubernetes cluster (no proxy between Metabase <-> Trino)
  • Trino setup: Docker container on VM, direct JDBC connection via internal SSL hostname from Metabase (https://trino.myinternaldomain.tld:8443)
  • Network flow: Very simple, Metabase pod -> Trino container url
  • Ingress proxy timeouts: Even though the kubernetes ingress shouldn't be a factor, for completion sake this is set to 1800s for the Metabase ingress.

Observations:

  • Short queries (<60s) execute successfully through Metabase → Trino
  • Long-running queries (>60s):
    • Appear in Trino UI instantly (and run to completion in ~10m in this case)
    • Metabase cancels exactly at 60s (with the aforementioned isClosed error in logs)