Bookmarked filter values on a question do not return expected results

1

Hi there! I've encountered a bit of a curious issue. I've created a question that has four different filters, each a field filter for a different column. Normally, if you set the filter values and bookmark the resulting URL, you can load that question with all the filters applied and see the desired results. In this case, though, I'm getting a very small (1-2 record) subset of what should be ~60-70 rows.

If I remove all filters, load the report, then reset those very same values manually, the expected result set is returned.

Anybody seen anything like this before? I'm really stumped, but thought maybe the brain-trust over here would have some ideas?

Cheers,

-Chuck

2

Hi @chucklessmith

Post "Diagnostic Info" from Admin > Troubleshooting.

Which type of questions are you bookmarking - GUI or SQL?
If GUI, at which version did you create the bookmarks? You can check the query hash between the bookmark and after you re-set the filters to see the difference (it's just a base64 encoded string).

And if you check the browser developer Network-tab, then you can see the query used in the response of the request.

3

Hey @flamber, thanks for the response. Here's more detail.

I'm bookmarking a SQL native question, so the values in question are stored as query parameters.

Thank you for the reminder about the Network debugging option. I'd forgotten about that. Looking at data.native_form.query, I can see the filter values are replaced basically as expected at first glance.

Comparing the bookmarked query with the one that results from resetting the filters as I explained earlier, a diff on the query strings shows they are identical, but the result sets are different.

Diagnostic info:

{
  "browser-info": {
    "language": "en-US",
    "platform": "MacIntel",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36",
    "vendor": "Google Inc."
  },
  "system-info": {
    "file.encoding": "UTF-8",
    "java.runtime.name": "Java(TM) SE Runtime Environment",
    "java.runtime.version": "1.8.0_111-b14",
    "java.vendor": "Oracle Corporation",
    "java.vendor.url": "http://java.oracle.com/",
    "java.version": "1.8.0_111",
    "java.vm.name": "Java HotSpot(TM) 64-Bit Server VM",
    "java.vm.version": "25.111-b14",
    "os.name": "Linux",
    "os.version": "3.13.0-48-generic",
    "user.language": "en",
    "user.timezone": "Etc/UTC"
  },
  "metabase-info": {
    "databases": [
      "h2",
      "redshift",
      "mysql",
      "postgres"
    ],
    "hosting-env": "unknown",
    "application-database": "mysql",
    "application-database-details": {
      "database": {
        "name": "MySQL",
        "version": "5.7.33-log"
      },
      "jdbc-driver": {
        "name": "MariaDB Connector/J",
        "version": "2.6.2"
      }
    },
    "run-mode": "prod",
    "version": {
      "tag": "v0.40.1",
      "date": "2021-07-14",
      "branch": "release-x.40.x",
      "hash": "ed8f9c8"
    },
    "settings": {
      "report-timezone": "UTC"
    }
  }
}

Worth noting I've also tried to run this on 0.40.2 (latest) and 0.39.1(previous version we were running in prod) under the same environment. The issue appears to occur in the same way for all versions.

4

OK, I see what's happening. The URL parameters generated by Metabase look like:

assignment=true and is_active=true

When set in the Metabase UI, the query rewrite happens with the boolean value TRUE. When processed by Metabase through the URL parameter, it's treating true as a string, causing the evaluation to fail in the query. You end up with:

assignment IN (TRUE)

vs.

assignment IN ('true')

Setting the URL parameter's value to 1 rather than true causes the report to load correctly via URL parameter input. Seems like this URL treatment might be useful logic to implement?

5

@chucklessmith You are seeing this issue:
https://github.com/metabase/metabase/issues/15498 - upvote by clicking :+1: on the first post

6

Thanks for helping me track that down. I was obviously not searching for the right keywords on my first pass. Much appreciated!

7

@chucklessmith
I didn't search - I could just remember the issue - that makes it much faster for me to find stuff :wink:
But this issue is a tricky one and something we're looking into the past couple of weeks, since the URL should of course behave exactly the same as doing it in-app.