<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary [BulkMemberAccessLoad](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/concerns/bulk_member_access_load.rb) is used to memoize max member access in projects and groups so we don't have to query the database each time we ask (Using `SafeRequestStore`). [This line](https://gitlab.com/gitlab-org/gitlab/-/blob/64ada62a60172dff2c70a2c9636492651e8e7d1c/app/models/concerns/bulk_member_access_load.rb#L45) returns the key to store the max access in this format `"max_member_access_for_#{klass.name.underscore.pluralize}:#{memoization_index}"`. But, memoization_index makes no diferentiation if the stored ID is from a project or a group. So, if you get the max access for a group with ID=6 and it is `MAINTAINER`, it will be stored in the SafeRequestStore as `max_member_access_for_users:6`. If you ask for the max member access for a project with ID=6 on the same request, you will get `MAINTAINER` without it getting to the DB. <!-- Summarize the bug encountered concisely. --> ### Steps to reproduce Didn't get to test on the API or any other place than specs yet, so might not be possible to accomplish from any of our external APIs. Probably easier to test in the GQL API by multiplexing. So, make a request that authorizes read_group where you have access. In the same request try to read a project with the same ID as the group, and you will get access even if you don't. This also happens in the opposite direction, if you get max access for the project with no access, the trying to read the group will fail because no access for that group ID is already memoized. Sample queries described in https://gitlab.com/gitlab-org/gitlab/-/issues/336802#note_636855209 <!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. --> ### What is the expected *correct* behavior? Memoization on the request store should also store the model the ID belongs to. <!-- Describe what you should see instead. --> ### Possible fixes Possibly changing [this line](https://gitlab.com/gitlab-org/gitlab/-/blob/64ada62a60172dff2c70a2c9636492651e8e7d1c/app/models/concerns/bulk_member_access_load.rb#L45) to use the model as part of the key is enough. Might affect several places where `BulkMemberAccessLoad`'s methods are called. <!-- If you can, link to the line of code that might be responsible for the problem. -->