- Perform actions on the repository through the GitLab user interface, such as
applying suggestions or using the GitLab IDE.
Gitaly typically calls this endpoint. It is only called internally (by other parts
of the application) rather than by external users of the API.
## Push checks
A key part of the `internal/allowed` flow is the call to
`EE::Gitlab::Checks::PushRuleCheck`, which can perform the following checks:
-`EE::Gitlab::Checks::PushRules::CommitCheck`
-`EE::Gitlab::Checks::PushRules::TagCheck`
-`EE::Gitlab::Checks::PushRules::BranchCheck`
-`EE::Gitlab::Checks::PushRules::FileSizeCheck`
## Recursion
Some of the Gitaly RPCs called by `internal/allowed` then, themselves, make calls
back to `internal/allowed`. These calls are now correlated with the original request.
Gitaly relies on the Rails application for authorization, and maintains no permissions model itself.
These calls show up in the logs differently to the initial requests. {example}
Because this endpoint can be called recursively, slow performance on this endpoint can result in an exponential performance impact. This documentation is in fact adapted from [the investigation into its performance](https://gitlab.com/gitlab-org/gitlab/-/issues/222247).
## Known performance issues
### Refs
The number of [`refs`](https://git-scm.com/book/en/v2/Git-Internals-Git-References)
on the Git repository have a notable effect on the performance of `git` commands
called upon it. Gitaly RPCs are similarly affected. Certain `git` commands scan
through all refs, causing a notable impact on the speed of those commands.
On the `internal/allowed` endpoint, the recursive nature of RPC calls mean the
ref counts have an exponential effect on performance.
