Woocommerce-ios: Clarify Product Update Errors for Users and for Troubleshooting during Support

[rezzap]

Is your feature request related to a problem? Please describe.

We are having users report error with editing products in the app. The logs are giving us the following error:

Error updating Product: The operation couldn't be completed. (Yosemite.ProductUpdateError error 2.)

Describe the solution you'd like

It would be good to have the app provide more details about the actual error for support purposes. 'error 2' is not very clear.

Describe alternatives you've considered

I'm not sure what the error is about exactly at this point.

Additional context

p1597153532050400-slack-C03URUK5C

[shiki]

Looking at the user logs, the errors (in release 4.6) are all ProductUpdateError.unknown:

https://github.com/woocommerce/woocommerce-ios/blob/25fa3fe62436027412818b1dc412b0f27fd153cc/Yosemite/Yosemite/Stores/ProductStore.swift#L529

It also looks like if we receive errors like network time outs, we do not propagate that to the user. I saw one user who had quite a few time out errors but when it comes to updating a product, we do not present that error to the user. We only show a "Cannot update product" error message:

We have custom errors for SKU problems though:

https://github.com/woocommerce/woocommerce-ios/blob/25fa3fe62436027412818b1dc412b0f27fd153cc/WooCommerce/Classes/ViewRelated/Products/Edit%20Product/Error%20Handling/ProductUpdateError%2BUI.swift#L14-L24

Suggested Resolution

I think we can improve these by:

1. Making sure that we handle and present errors to the user. At least these should be included:
   
   
   
   • HTTP 400 (we should be aware of errors like this since it's most probably a problem with how we communicate with the API)
   
   
   • Time outs
   
   
   • HTTP 401 (permissions problems)
   
   
2. If we receive errors like the ones above, we should display that to the user so users are better informed.
3. We should log the original HTTP error if we can. So if there's an error that we shouldn't show to the user, we can at least take care of it in support.

I think the errors can be taken from DotcomError. The solution should probably be standardized so we can use the messages throughout the app and not just ProductUpdateError.

[shiki]

@rezzap To answer your question directly, we currently hide the errors and it looks like there's no way to determine what the original errors were. Some were most probably time out errors.

In my comment above https://github.com/woocommerce/woocommerce-ios/issues/2636#issuecomment-672195105, I'm proposing that we capture and display all these errors so we can better support our users.

---

I'll rename this issue and add it to the Products M3 backlog.

[shiki]

FYI @jaclync and @pmusolino

[jaclync]

Thanks for raising this! For this specific product update error, the server tells us it's a 400 error with the response body:

{
  "error" : "rest_invalid_param",
  "message" : "Invalid parameter(s): date_on_sale_to_gmt"
}

Since the message could be anything and meant for developers only (users wouldn't know what date_on_sale_to_gmt is 😅 ), right now we don't have a good way to show more details to the user. However, I think we should still propagate the error to ProductUpdateError so that we can log the details to Sentry or DDLog.

[shiki]

@jaclync Yeah, we probably shouldn't use the message given by the API. I think a 400 is most of the time and showing "unexpected error" would probably be appropriate. I think that's good enough to inform them that it's not a network issue and it could not be resolved. We should probably iterate on the possible errors and messages with Garance of course. 😅

And I agree that we should log the full message in Sentry/DDLog. 👍