Add "Retry" button to ReportError component

Feature Description

Currently when the user encounters an error that causes ReportError to be displayed, there is no way to retry the request. We should add a “retry” button that invalidates the request’s resolver and forces the request to be tried again.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• A “Retry” button should be added to the ReportError component whenever the return value from getErrorForSelector contains the selectorData object.
• Other than that, there are a few exceptions where the button should not be shown if any of the following is true:
  • If the selectorName is not getReport (because then it could be any other type of error that is not from the report API request) - @eugene-manuilov raised this earlier today, and it makes sense to me.
  • If the error is an “insufficient permissions error”, i.e. the user doesn’t have access to this data. In that case, they will have to coordinate with the admin who does have access so that they can get access to. That’s not exactly a quick task (unless they’re sitting right next to them), so we probably shouldn’t show the Retry button there as it’s not going to help.
  • If the error is a “permission scope error”, i.e. the user hasn’t granted certain OAuth scopes. In that case they will see a banner notification to fix this anyway, and retrying the request won’t do it.
  • If the error has a reconnectURL with it, i.e. there is already a CTA URL present which can fix the problem - again retrying the request won’t do it in this case.
• When activated, the button should use this code:

dispatch(selectorData.storeName)
  .invalidateResolution(
    selectorData.name,
    selectorData.args
  );

to clear the error.

Implementation Brief

• In assets/js/components/notifications/CTA.js component:
  • Take two new props retry which is a boolean and onRetry which is a function.
    • Both props are optional.
  • When the retry prop is true, render a Button component with the following:
    • onClick should be onRetry.
    • Children should be translated string Retry.
• In assets/js/components/ReportError.js component:
  • When the passed error prop has a selectorData object-
    • Define a callback function for the retry handler which dispatches the invalidateResolution action like it is shown in the AC.
    • Pass retry to the CTA element.
    • Pass the aforementioned retry handler function to the onRetry prop of the CTA element.

Test Coverage

• Add story with the Retry Button on assets/js/components/ReportError.stories.js. We can do it without waiting for the blocker issue by passing an object of same shape as the error prop.

QA Brief

• Ensure the newly added story has a Retry button. The following link will work once the PR gets merged: https://google.github.io/site-kit-wp/storybook/develop/?path=/story/components-reporterror--report-error-with-retry-button Otherwise, it can be found here: https://google.github.io/site-kit-wp/storybook/pull/5337/?path=/story/components-reporterror--report-error-with-retry-button
• Verify the Retry button appears as per the AC, if the error is the getReport data error and is not any of the following:
  • Is not an “insufficient permissions error”
  • Is not a “permission scope error”
  • Is not an auth error that has error.data. reconnectURL
• A getReport error can be simulated by using an HTTP proxy/request proxy and having requests to the Site Kit API (example: http://sitekit.10uplabs.com/wp-json/google-site-kit/v1/modules/search-console/data/searchanalytics) fail/abort. This should cause the “retry” button to appear, and when clicked trigger the request again.
• Refer to this comment. It’s almost the same as the AC.

Update:

@felixarntz spotted an issue with Adsense getReport errors (refer to this comment).

Also, refer the investigation and the proposed solution by @tofumatt here.

• To replicate this using Proxyman, set a breakpoint with a wildcard for the API requests like so http://sitekit.10uplabs.com/wp-json/google-site-kit/v1/*.
• The domain has to be your local or the test site’s domain.
• Abort all the report requests.
• Verify the Retry button appears.
• When clicking the Retry button the requests should be sent and this time execute the requests from the Proxyman.
• Verify the data appears on the widget.

Changelog entry

• Add a “retry” button for HTTP requests that encountered an error on the dashboard.

[felixarntz]

@hussain-t @bethanylang @aaemnnosttv @tofumatt Based on today’s conversation, I suggest the following refinement here:

• Instead of showing the Retry button on all ReportErrors (i.e. the red border in-widget errors), we limit it by adding a number of exceptions where the button should not be shown if any of the following is true:
  • If the selectorName is not getReport (because then it could be any other type of error that is not from the report API request) - @eugene-manuilov raised this earlier today, and it makes sense to me.
  • If the error is an “insufficient permissions error”, i.e. the user doesn’t have access to this data. In that case, they will have to coordinate with the admin who does have access so that they can get access to. That’s not exactly a quick task (unless they’re sitting right next to them), so we probably shouldn’t show the Retry button there as it’s not going to help.
  • If the error is a “permission scope error”, i.e. the user hasn’t granted certain OAuth scopes. In that case they will see a banner notification to fix this anyway, and retrying the request won’t do it.
  • If the error has a reconnectURL with it, i.e. there is already a CTA URL present which can fix the problem - again retrying the request won’t do it in this case.

In order to implement the last three without duplicating too much, we should rely on helper functions like isInsufficientPermissionsError( error ), isPermissionScopeError( error ), and isAuthError( error ) which we can then call here. The last two should also be used in the existing dispatchAPIError function (which I used as a reference to define the last two conditions above). The first two helper functions already exist, so let’s add an isAuthError to them. We can then use these small helpers in both ReportError and dispatchAPIError as applicable.

Let me know what you think.

[tofumatt]

@mohitwp When I tested this I was using an HTTP proxy (Proxyman, though Charles or other proxies would work too) and adding a breakpoint to all requests using Tools > Breakpoints > Add Rule:

Whatever HTTP proxy you’re using, adding breakpoints to http://sitekit.10uplabs.com/wp-json/google-site-kit/v1/* will let you control the response from those requests. You can change http://sitekit.10uplabs.com to whatever your testing site’s URL is, and this will let you control whether the Site Kit API request goes through or not.

If you abort the request, it will be an HTTP fetch failure that should trigger the retry button. It’s exactly what I did when testing:

Alternatively, you could probably insert code into the plugin to cause that request to fail, eg: https://github.com/google/site-kit-wp/blob/affa782aab7b74ad44d8dbb55cdc6a5f2d854806/includes/Modules/Search_Console.php#L213. Adding a die('Foo.'); right before this line should work, but I proposed the HTTP proxy because it means using exactly the production code to test.

Does that help?