### 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  Grouping by Epic doesn't show the right amount of issues, 'test epic 1' should have 10 issues  After reloading the page or searching with an empty box the right number of issues are shown  ### Output of checks <!-- If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com --> #### Results of GitLab environment info <details> <summary>Expand for output related to GitLab environment info</summary> <pre> 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://<redacted> HTTP Clone URL: https://<redacted>/some-group/some-project.git SSH Clone URL: git@<redacted>: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 </pre> </details> #### Results of GitLab application Check <details> <summary>Expand for output related to the GitLab application check</summary> <pre> 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 </pre> </details> ### Possible fixes This issue looks kinda the same, but the fix described here https://gitlab.com/gitlab-org/gitlab/-/issues/327336#note_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 ```