Add latest changes from gitlab-org/gitlab@master

4 files changed, 59 insertions, 2 deletions

diff --git a/doc/development/dangerbot.md b/doc/development/dangerbot.md
index b30ac0f0748..cd884a023ca 100644
--- a/doc/development/dangerbot.md
+++ b/doc/development/dangerbot.md
@@ -18,7 +18,7 @@ to the existing rules, then this is the document for you.
 A subset of the current checks can be run locally with the following rake task:
 
 ```shell
-bundle exec danger_local
+bin/rake danger_local
 ```
 
 ## Operation
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 336a808b793..68c0c1e3370 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -371,6 +371,54 @@ it('calls mutation on submitting form ', () => {
 });
 ```
 
+## Handling errors
+
+GitLab's GraphQL mutations currently have two distinct error modes: [Top-level](#top-level-errors) and [errors-as-data](#errors-as-data).
+
+When utilising a GraphQL mutation, we must consider handling **both of these error modes** to ensure that the user receives the appropriate feedback when an error occurs.
+
+### Top-level errors
+
+These errors are located at the "top level" of a GraphQL response. These are non-recoverable errors including argument errors and syntax errors, and should not be presented directly to the user.
+
+#### Handling top-level errors
+
+Apollo is aware of top-level errors, so we are able to leverage Apollo's various error-handling mechanisms to handle these errors (e.g. handling Promise rejections after invoking the [`mutate`](https://www.apollographql.com/docs/react/api/apollo-client/#ApolloClient.mutate) method, or handling the `error` event emitted from the [`ApolloMutation`](https://apollo.vuejs.org/api/apollo-mutation.html#events) component).
+
+Because these errors are not intended for users, error messages for top-level errors should be defined client-side.
+
+### Errors-as-data
+
+These errors are nested within the `data` object of a GraphQL response. These are recoverable errors that, ideally, can be presented directly to the user.
+
+#### Handling errors-as-data
+
+First, we must add `errors` to our mutation object:
+
+```diff
+mutation createNoteMutation($input: String!) {
+  createNoteMutation(input: $input) {
+    note {
+      id
++     errors
+    }
+  }
+```
+
+Now, when we commit this mutation and errors occur, the response will include `errors` for us to handle:
+
+```javascript
+{
+  data: {
+    mutationName: {
+      errors: ["Sorry, we were not able to update the note."]
+    }
+  }
+}
+```
+
+When handling errors-as-data, use your best judgement to determine whether to present the error message in the response, or another message defined client-side, to the user.
+
 ## Usage outside of Vue
 
 It is also possible to use GraphQL outside of Vue by directly importing
diff --git a/doc/development/go_guide/index.md b/doc/development/go_guide/index.md
index f6aae945f62..59efc7be2f4 100644
--- a/doc/development/go_guide/index.md
+++ b/doc/development/go_guide/index.md
@@ -302,7 +302,7 @@ There are a few guidelines one should follow when using the
   fields in the context of that code path, such as the URI of the request using
   [`WithField`](https://godoc.org/github.com/sirupsen/logrus#WithField) or
   [`WithFields`](https://godoc.org/github.com/sirupsen/logrus#WithFields). For
-  example, `logrus.WithField("file", "/app/go).Info("Opening dir")`. If you
+  example, `logrus.WithField("file", "/app/go").Info("Opening dir")`. If you
   have to log multiple keys, always use `WithFields` instead of calling
   `WithField` more than once.
 
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index f4844cb14d1..58e802a9d27 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -545,6 +545,15 @@ why without editing the source and rerun the tests.
 
 This is especially useful whenever it's showing 500 internal server error.
 
+Prefer named HTTP status like `:no_content` over its numeric representation
+`206`. See a list of [supported status codes](https://github.com/rack/rack/blob/f2d2df4016a906beec755b63b4edfcc07b58ee05/lib/rack/utils.rb#L490).
+
+Example:
+
+```ruby
+expect(response).to have_gitlab_http_status(:ok)
+```
+
 ### Shared contexts
 
 Shared contexts only used in one spec file can be declared inline.