Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

let backend processors specify the response error code #78

Closed
mrcpvn opened this issue Mar 23, 2017 · 1 comment
Closed

let backend processors specify the response error code #78

mrcpvn opened this issue Mar 23, 2017 · 1 comment

Comments

@mrcpvn
Copy link

mrcpvn commented Mar 23, 2017

the BackendGateway will always return FailBackendTransaction (554) if there is an error in one of the backend processors.
It would be useful if the error specified from the processor would be parsed and returned if valid...similar to this:

// wait for the save to complete
        // or timeout
        select {
        case status := <-workerMsg.notifyMe:
                defer workerMsgPool.Put(workerMsg) // can be recycled since we used the notifyMe channel
                if status.err != nil {
                        if _, err := strconv.Atoi(status.err.Error()[:3]); err != nil {
                                return NewResult(response.Canned.FailBackendTransaction + status.err.Error())
                        }
                        return NewResult(status.err.Error())
                }
                return NewResult(response.Canned.SuccessMessageQueued + status.queuedID)

        case <-time.After(gw.saveTimeout()):
                Log().Error("Backend has timed out while saving eamil")
                return NewResult(response.Canned.FailBackendTimeout)
        }

in this way the backend could respond 421 (for example) and allow the client to retry to send the email.

Another solution could be to add the backend result in the notifyMsg (or a pointer to it)

@flashmob
Copy link
Owner

flashmob commented Mar 24, 2017

Yeah, you're right - it's a limitation.

Would need to have a think about it. It seems like backend.Result and error could be married together. This is because there is only one result that is OK, all other result types are errors. So in other words, backend.Result could implement the error interface, and also have the ability to return the error as a response.

Edit: formatting

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants