[MBL-1346] Support User Friendly Validate Checkout Error Messaging

[scottkicks]

📲 What

Displays more user-friendly error messaging from the backend if the ValidateCheckout call fails.

🤔 Why

Error messaging can now make more sense and provide more context to users than the generic "Something went wrong" messaging we currently have.

🛠 How

• Add a new static func in ErrorEnvelope.swift that creates an envelope specific to this use case
• Add a check in ValidateCheckoutEnvelope.envelopeProducer() that returns an ErrorEnvelope if we could parse the GraphAPI JSON, but the server deemed the checkout invalid.
• Pass the returned error message, if there is one, to the error message banner

✅ Acceptance criteria

• No changes to late pledge flow

Review Recommendation

• All at once instead of commit by commit. Adjusted my plan along the way so the commits will likely be a bit confusing.

[ifosli]

I find this approach confusing, since we'd now have a ValidateCheckoutEnvelope with valid = false and an ErrorEnvelope that basically mean the same thing. Left a more detailed comment with suggestions (that basically proposes we get rid of one of them). I'm glad we're getting better error messaging, though!

Also, note: Iirc, in the case where the error is "This payment method isn't valid for this project", I'm pretty sure we don't want to bump the user back to the confirm details page. This might be a different ticket/pr, but just wanted to raise it so you're aware of it in case it matters for your approach, since we'll want to differentiate between "error that restarts checkout" and "error that tells the user to just try something else from here".

[ifosli]

This doesn't make sense to me. If we're always going to say that valid == false means we create an error envelope instead, why would we have a valid field at all on the ValidateCheckoutEnvelope? What do you think of either a) using the current valid field in the postCampaignCheckoutVM to decide if we should show an error banner or not or b) getting rid of the valid field entirely and instead create the errorEnvelope immediately once we see the checkout isn't valid?

[scottkicks]

@ifosli 🤔 Yea we could remove valid from ValidateCheckoutEnvelope and instead of
if envelope.valid == false {...} we could just check the checkout object directly like this

guard data.checkout?.isValidForOnSessionCheckout.valid == true else {...}

Is that what you mean?

[scottkicks]

I do think that it's useful to differentiate between .couldNotParseJSON and .validateCheckoutError ErrorEnvelopes, though.

I also considered removing messages in the same way because the extra validateCheckoutEnvelope() seems excessive and not super useful for this case.

[scottkicks]

I went ahead and[ removed valid from the envelope](remove redundant valid property from ValidateCheckoutEnvelope) so that we just have the one!

As for updating the UX so that users who attempt to pledge with an invalid payment method, I already have a separate ticket to address this 😄 . Bessie should be adding an errorTypes array to this mutation that I think we can expose and then use to do that.

[ifosli]

A couple minor things - please do handle the "server doesn't have any error messages for us" case before merging - but overall looks good!

[ifosli]

nit: 200 seems like a weird choice for the http code for an error

[scottkicks]

Well, in this case, technically, the request was sent successfully even though there was an error on the backend. A 400 (Bad Request) didn't make much sense to me either.

[ifosli]

Nit: I think the message param here should be optional instead of passing in the empty string, so that we can show the "Something went wrong" default (instead of a banner with an empty string) if the server doesn't give us an error message for some weird reason. Or we could just pass in the entire list of messages instead; that might make more sense actually.