Gracefully handle query timeouts for project VSA
What does this MR do?
Ensures we gracefully handle BE query request timeouts when fetching stage data for project level value streams. When there is too much data to process, the API will raise a timeout, the api request will succeed but an error message is added to the response payload.
This MR checks for the error response and displays it to the user if it is available. This will usually be a message about
there being too much data to display
.
NOTE: this is mostly because we don't have pagination for the stage table, that will be available once we replace this table with the group level value stream table in #326704 (closed)
Testing instructions
- Navigate to a project value stream, ie https://gitlab.com/gitlab-org/gitlab/-/value_stream_analytics
- Click between stages, you will either see data (if you have seeded some) or an empty stage saying 'Not enough data'
- Apply this patch:
diff --git a/app/controllers/projects/cycle_analytics/events_controller.rb b/app/controllers/projects/cycle_analytics/events_controller.rb
index 3a5dd23047c..09c7cc1349f 100644
--- a/app/controllers/projects/cycle_analytics/events_controller.rb
+++ b/app/controllers/projects/cycle_analytics/events_controller.rb
@@ -14,28 +14,39 @@ class EventsController < Projects::ApplicationController
feature_category :planning_analytics
def issue
+ raise ActiveRecord::QueryCanceled
+
render_events(cycle_analytics[:issue].events)
end
def plan
+ raise ActiveRecord::QueryCanceled
+
render_events(cycle_analytics[:plan].events)
end
def code
+ raise ActiveRecord::QueryCanceled
+
render_events(cycle_analytics[:code].events)
end
def test
+ raise ActiveRecord::QueryCanceled
options(cycle_analytics_project_params)[:branch] = cycle_analytics_project_params[:branch_name]
render_events(cycle_analytics[:test].events)
end
def review
+ raise ActiveRecord::QueryCanceled
+
render_events(cycle_analytics[:review].events)
end
def staging
+ raise ActiveRecord::QueryCanceled
+
render_events(cycle_analytics[:staging].events)
end
- Refresh your project value stream, the
Too much data
error should be shown
Screenshots (strongly suggested)
Before | After |
---|---|
Does this MR meet the acceptance criteria?
Conformity
-
I have included a changelog entry, or it's not needed. (Does this MR need a changelog?) -
I have added/updated documentation, or it's not needed. (Is documentation required?) -
I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?) -
I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?) -
I have self-reviewed this MR per code review guidelines. -
This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines) -
I have followed the style guides.
Availability and Testing
-
I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.) -
I have tested this MR in all supported browsers, or it's not needed. -
I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.
Security
Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team