1130573 - Replace TRANS_NOT_FOUND with the real error

Status: RESOLVED FIXED

(Marketplace Graveyard :: Payments/Refunds, defect, P2)

Description

[Kumar McMillan [:kumar]]

When you begin a transaction in Spartacus, the system asynchronously queues a transaction (which calls one of our provider APIs) then waits until the transaction is ready. When an unexpected error occurs, Spartacus always times out waiting for the transaction and says TRANS_NOT_FOUND. I think we can fix this by saving details about the unexpected error on the transaction itself so that Spartacus can show the correct error. This will make debugging issues found by QA go a lot quicker.

Comment 1

[Kumar McMillan [:kumar]]

Hmm, I'm not sure if we can make this error code more useful without chasing our tails. We typically encounter a bunch of unexpected exceptions:

- ValueError: mis-configured seller/product in solitude
- ObjectDoesNotExist: can't find some solitude object
- HTTPError: API error when talking to solitude

We could map each of these to an error code but I'm not sure yet if it's worth it. It will require a lot of introspection to find out what the actual error is. For example, a general curling http error is hard to turn into something meaningful.

Comment 2

[Andy McKay]

How about:

* ValueError, ObjectDoesNotExist: are both Product Configuration errors and are fatal errors we can't do anything about.
* HTTPError: is a temporary error that can be fixed by a retry?

And log verbosely somewhere so we can fix later? Once we've got something in place to send more detailed errors we can iterate as we hit new errors.

Comment 3

[Kumar McMillan [:kumar]]

an HTTPError is not a temporary error. It could mean that 1) solitude had a traceback or 2) the API (e.g. Boku) that Solitude is proxying returned an error. I guess we could differentiate between 500 and 40x responses. Still not sure if it's helpful. 

btw, all of this logged as is :) And it's easy to find in Sentry. This bug was created in hopes that we could *display* a more meaningful code but without displaying a traceback on the screen I'm not sure how meaningful we can make it. The traceback will already be in the logs and in Sentry.

Comment 4

[Andy McKay]

We got this in bug 1149095 and related bugs which allows us to pass up the errors. The challenge is to find a TRANS_NOT_FOUND and figure out the appropriate error is. But that should be pretty rare now, we'll likely hit more UNEXPECTED_ERRORS :(