Group by Epic on issue board doesn't show the right amount of issues

Summary

Selecting 'Group by: Epic' on an issue board shows the wrong number of issues per epic if the issues are not all loaded on the initial load. After a refresh of the page (or pressing enter/return in the search bar) the correct number of issues is shown.

Steps to reproduce

  1. Create 2 epics

  2. Create 4 labels

  3. Create an issue board with 4 columns from the labels, make sure one of columns is out of view

  4. Add 11 or more issues to the column/label out of view, add them to an epic

  5. Go to the issue board (the column out of view will load 10 issues, if you would scroll to the column the remaining issues would get loaded)

  6. Select 'Group by: Epic'

  7. The Epics will only show issues that were initially loaded

  8. Refresh page or empty search will refresh the issues to the correct state

Example Project

Can't create a project on gitlab.com, Epics are a premium feature.

What is the current bug behavior?

Selecting group by Epic results in the wrong number of issues for epics. Expanding the Epic also doesn't show the correct amount of issues. Refreshing the page (via F5 or hitting the search bar) makes the issue count correct

What is the expected correct behavior?

Selecting group by Epic should result in the correct amount of issues and expanding the Epic should show the correct issues under the Epic.

Relevant logs and/or screenshots

Example of the issue board where the list with the issues are out of view label-4-out-of-view

Grouping by Epic doesn't show the right amount of issues, 'test epic 1' should have 10 issues wrong-number-of-epics

After reloading the page or searching with an empty box the right number of issues are shown right-number-after-search

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 
System information
System:         Debian 9.13
Proxy:          no
Current User:   git
Using RVM:      no
Ruby Version:   2.7.4p191
Gem Version:    3.1.4
Bundler Version:2.1.4
Rake Version:   13.0.6
Redis Version:  6.0.16
Git Version:    2.33.0.
Sidekiq Version:6.2.2
Go Version:     unknown

GitLab information
Version:        14.4.1-ee
Revision:       abc23a14bac
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     PostgreSQL
DB Version:     12.7
URL:            https://
HTTP Clone URL: https:///some-group/some-project.git
SSH Clone URL:  git@:some-group/some-project.git
Elasticsearch:  no
Geo:            no
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers: 

GitLab Shell
Version:        13.21.1
Repository storage paths:
- default:      /var/opt/gitlab/git-data/repositories
GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell
Git:            /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check 
Checking GitLab subtasks ...                                                                                                                                                           [7/47]

Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 13.21.1 ? ... OK (13.21.1)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Gitaly ...


Gitaly: ... default ... OK


Checking Gitaly ... Finished


Checking Sidekiq ...


Sidekiq: ... Running? ... yes

Number of Sidekiq processes (cluster/worker) ... 1/1


Checking Sidekiq ... Finished


Checking Incoming Email ...


Incoming Email: ... Checking Reply by email ...


IMAP server credentials are correct? ... no
Exception: undefined method `message' for #String:0x00007fa57cd092c8
Init.d configured correctly? ... skipped

MailRoom running? ... skipped


Checking Reply by email ... Finished


Checking Incoming Email ... Finished


Checking LDAP ...


LDAP: ... LDAP is disabled in config/gitlab.yml


Checking LDAP ... Finished


Checking GitLab App ...


Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
2/1 ... yes
5/2 ... yes
7/3 ... yes
10/4 ... yes
Redis version >= 5.0.0? ... yes
Ruby version >= 2.7.2 ? ... yes (2.7.4)
Git version >= 2.33.0 ? ... yes (2.33.0)
Git user has default SSH configuration? ... yes
Active users: ... 6
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Elasticsearch version 7.x (6.4 - 6.x deprecated to be removed in 13.8)? ... skipped (elasticsearch is disabled)


Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Possible fixes

This issue looks kinda the same, but the fix described here #327336 (comment 590520844) does not work. I've made sure the graphql_board_lists and board_new_list feature flags are enabled:

irb(main):001:0> Feature.enabled?(:graphql_board_lists)
=> true
irb(main):002:0> Feature.enabled?(:board_new_list)
=> true