Skip to content

Advanced Global Search sorting/relevance is only using updated_at

Summary

I just tried this search https://gitlab.com/search?utf8=%E2%9C%93&snippets=false&scope=issues&repository_ref=master&search=elasticsearch+AND+storage&group_id=9970&project_id=278964 . I'm trying to find an issue where I did an analysis of elasticsearch storage used. I tried a bunch of combinations of those words and didn't find it. I found it in my inbox and it is #195764 (closed) . It doesn't appear on the first page of results. But the first result for me is #21191 (closed) which does not seem to actually mention elasticsearch or storage and I'm not sure why it's there at all. I'm going to look further into this to understand why our relevance is behaving so strange here but it may be due to a bad sort order or something else. Weirdly I feel that this is just happening to me today and actually I've had great success with issue search over the last few weeks. I can't think of anything that's changed recently related to this either.

Our query has this for sorting:

  "sort": [
    {
      "updated_at": {
        "order": "desc"
      }
    },
    "_score"
  ],

This is actually a major cause of the problems as it's saying the updated_at date is more important than the _score. If I remove that from the sort I actually get my issue first up. I can't imagine this was added recently though...

We can combine the recency of the document with score for relevance but this is not the way to do it because it means the score/relevance of the document isn't even being considered unless the updated_at is equal (which it basically never will be since it's a timestamp)

Steps to reproduce

(How one can reproduce the issue - this is very important)

Example Project

(If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report)

(If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version)

What is the current bug behavior?

(What actually happens)

What is the expected correct behavior?

(What you should see instead)

Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise.)

Output of checks

(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of: sudo gitlab-rake gitlab:check SANITIZE=true)

(For installations from source run and paste the output of: sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)

(we will only investigate if the tests are passing)

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)