### Problem to solve If Gitaly becomes unreachable, there are various places throughout the application that will be impacted. This includes: - Dashboard - Exploring projects - Accessing a repository - File browsing It was [previously discussed](https://gitlab.com/gitlab-org/gitlab/issues/34722#note_260557148) that we show a warning alert and identify projects that are affected along with information regarding why we can't load all the information requested, and what can be done to resolve the issue. The problem is that, in order to identify projects that are affected, we'd need to request the uncached status from Gitaly, which would increase the load to Gitaly at a time when it is unstable or unreachable. Additionally, these statuses would ideally need to be displayed across the application since there will be several different pages impacted. We'll need to solve communicating more broadly what the status is, versus individually on pages or projects. ### Intended users All personas would be affected by Gitaly being unreachable. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> As discussed in https://gitlab.com/gitlab-org/gitlab/-/issues/205488#note_329787521: Show a warning message that something went wrong (when `GRPC::Unavailable` and `GRPC::DeadlineExceeded` were raised) and not all content are displayed. Do this for every request including AJAX ones but the message should only show once and on the page where the problem was experienced. <details> <summary>Previous Proposal</summary> We want to communicate to users these things: * **What** the problem is and what it may cause (Gitaly is unreachable, XYZ data will be unavailable) * **How** can it be resolved One suggestion is to [display a custom 500 error page](https://gitlab.com/gitlab-org/gitlab/issues/34722#note_287782034) when the user tries to access a project that is unreachable, and to [monitor Gitaly's server status](https://gitlab.com/gitlab-org/gitlab/issues/34722#note_286609123) in order to show a global warning alert. </details> ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> ### Availability & Testing * As noted, availability could be affected if monitoring Gitaly's status adds additional load when it's already unstable. * Unit/integration tests should provide most of the coverage, but a new E2E test should be added for extra confidence. * The change isn't expected to affect existing E2E tests. ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ### Links / references