Public Download link does not work. Private does work

1

We've had a query that's been in use for quite some time. The last time my user was able to successfully download from the public link was 12/13 around midday. He reported the issue on 12/18. On 12/8 we switched from being locked to v0.47.4 to allowing updates and updated on 12/8 to 0.47.9. Then, the docker images we use updated to 0.48 on 12/14...

We have not noticed this on other dashboards. We have adjusted the URL configuration to from https to HTTP (didn't help) so we altered it back to https. Again, this works on other queries, just not this one.

Behavior:
Private (editing) URL works fine for downloading the results.
Public URL gives this:

<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
<hr><center>openresty</center>
</body>
</html>
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->

The question has 17 variables, all of which are field filters.

If you remove any 3 of the variables, dropping the variable count down to 14, the public URL download will work as expected.

Diagnostic Info:

{
  "browser-info": {
    "language": "en-US",
    "platform": "Win32",
    "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
    "vendor": "Google Inc."
  },
  "system-info": {
    "file.encoding": "UTF-8",
    "java.runtime.name": "OpenJDK Runtime Environment",
    "java.runtime.version": "11.0.21+9",
    "java.vendor": "Eclipse Adoptium",
    "java.vendor.url": "https://adoptium.net/",
    "java.version": "11.0.21",
    "java.vm.name": "OpenJDK 64-Bit Server VM",
    "java.vm.version": "11.0.21+9",
    "os.name": "Linux",
    "os.version": "6.2.0-1018-azure",
    "user.language": "en",
    "user.timezone": "US/Central"
  },
  "metabase-info": {
    "databases": [
      "sqlserver"
    ],
    "hosting-env": "unknown",
    "application-database": "mysql",
    "application-database-details": {
      "database": {
        "name": "MariaDB",
        "version": "10.9.8-MariaDB-1:10.9.8+maria~ubu2204"
      },
      "jdbc-driver": {
        "name": "MariaDB Connector/J",
        "version": "2.7.10"
      }
    },
    "run-mode": "prod",
    "version": {
      "date": "2023-12-19",
      "tag": "v0.48.1",
      "hash": "a8302d4"
    },
    "settings": {
      "report-timezone": "US/Central"
    }
  }
}
2

For a bit more information, our metabase setup is run under docker on linux, using docker-compose. there's a proxy (nginx proxy manager, also in docker) that adds TLS and converts http://docker:3000 to https://dashboard.ourdomain.com, the URL our users use to access metabase.

The metabase container is auto-updated via watchtower.

The 502 error is coming from the proxy. If I access the public link and try to download the results, it doesn't appear to do anything, but under dev tools\console, I get this error message:

metabase-console-error
metabase-console-error1048×66 6.77 KB

I've seen other posts about this where it says that the site URL is set wrong within metabase, but which URL should we use? The direct http://docker:3000 URL or the proxied address https://dashboard.ourdomain.com? If using the direct URL, should it be hostname or FQDN of the linux server hosting the metabase container, the proxied address that users will be using, or the name of the docker container that the proxy can access? It's currently set to the proxied address.

Also, in case it's helpful, when loading the public link, prior to attempting to download results, the dev tools console displays these error messages:

metabase-public-link-initial-console-error
metabase-public-link-initial-console-error1050×465 15.1 KB

3

you should use the true URL of the instance (dashboard.xxxxxx). Try changint to that and report back

4

ok, thanks for the clarification. that is the URL we have already been using all along.