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

Email requests using unverified email address in from field are not thrown #275

Closed
OussamaFadlaoui opened this issue Nov 26, 2023 · 4 comments

Comments

@OussamaFadlaoui
Copy link

Subject of the issue

I used the Node SDK package resend to send my first email. Upon using an unverified domain in the from field, my request seemed to go OK (promise was not rejected). When I went to the dashboard, I discovered the request was rejected with status code 403:
image
That's a valid point, however, why did the Promise not throw an appropriate error?

Steps to reproduce

  1. Create Resend account
  2. Install resend NPM package
  3. Send an email in Node.js using an unverified domain name in the from field

Expected behaviour

The promise should be rejected on 403 status codes..

Actual behaviour

No errors being thrown.

@bukinoshita
Copy link
Member

Hey @OussamaFadlaoui, would you mind sharing the request you're sending?

@everybodyloveshaggis
Copy link

everybodyloveshaggis commented Apr 11, 2024

@bukinoshita - an example I can give to back up @OussamaFadlaoui 's example is this

let data;
    try {
        data = await resend.emails.send({
            from: 'onboarding@resend.com',     //this is wrong on purpose to throw an error
            to: 'BLANKED_OUT_FOR_QUESTION_RESPONSE@gmail.com',
            subject: 'Message from cv-site-nextjs',
            reply_to: senderEmail as string,
            react: React.createElement(ContactFormEmail,
                {
                    senderMessage: senderMessage as string,
                    senderEmail: senderEmail as string
                }),
        });
        //interrogation required to check for error
        if(data.error?.message !== undefined)
        {
            throw data.error;
        }
    } catch (error: unknown) {
        return {
            error: getErrorMessage(error),
        };
    }

You'll see I have had to interrogate the data object to pull out the child error object with the below

 if(data.error?.message !== undefined)
        {
            throw data.error;
        }

as I do not hit the catch block even though the following error is displayed on the UI
image

@vcapretz
Copy link
Member

hey there, in the latest versions of the SDK basically all methods should always return correctly and not throw any errors, we do that so in your codebase you don't have to wrap our code in a try/catch method.

if the requests fail for any reason, our SDK will return a populated error object with some description of what happened.

using the example for an unverified domain the error object will be like:

{
  statusCode: 403,
  message: 'The test.com domain is not verified. Please, add and verify your domain on https://resend.com/domains',
  name: 'validation_error'
}

please let us know if the issue still persists and feel free to reopen it in here 🙏

@OussamaFadlaoui
Copy link
Author

hey there, in the latest versions of the SDK basically all methods should always return correctly and not throw any errors, we do that so in your codebase you don't have to wrap our code in a try/catch method.

if the requests fail for any reason, our SDK will return a populated error object with some description of what happened.

using the example for an unverified domain the error object will be like:

{
  statusCode: 403,
  message: 'The test.com domain is not verified. Please, add and verify your domain on https://resend.com/domains',
  name: 'validation_error'
}

please let us know if the issue still persists and feel free to reopen it in here 🙏

Obviously this is not my library, but I still want to say that having tries and catches all over code does not take away from the quality of a library. In fact, it is the proper way of handling errors. After all, this library is performing a promise, and promises are expected to either resolve or reject

Therefore I find the reasons for this design decision to be a bit odd and steering away from the traditional way of using promises in third party libraries.

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

4 participants