miguelszerman
Swoosh Sendgrid send email error 400 - How should I approach debugging it?
I am trying to send emails using Sendgrid with Swoosh. I tried the HTTP request and sent it with Postman, it works fine. When I try to do it with Swoosh, I get the error code 400 with Nginx - Bad Request.
How should I approach debugging this? I considered going through the library itself to understand what might be different between my request in Postman and Swoosh (since it’s unclear to me how Swoosh builds the HTTP request behind scenes).
defmodule PhoenixApp.PrepareEmail do
use Phoenix.Swoosh, view: PhoenixAppWeb.EmailView, layout: {PhoenixAppWeb.EmailView, :email_root}
def create_email(conn, email) do
new()
|> to({"someone", email})
|> from({"...name...", "...email..."})
|> reply_to({"...name...", "...email..."})
|> subject("...subject...")
|> text_body("hey there")
end
end
defmodule PhoenixApp.Mailer do
use Swoosh.Mailer, otp_app: :phoenix_app
end
defmodule PhoenixAppWeb.PageController do
use PhoenixAppWeb, :controller
def index(conn, _params) do
# Create Email
email = PhoenixApp.PrepareEmail.create_email(conn, email)
# Send Email
PhoenixApp.Mailer.deliver(email)
render(conn, "index.html")
end
end
First Post!
w0rd-driven
This comes from little experience with Swoosh but more of lending you brain power.
Does the email variable match what you’re sending in Postman? I can’t tell if that’s generic text for illustration purposes. I ask because sometimes you have to send what looks like an email address.
You could try tacking on an IO.inspect() call to your deliver method to see if anything returns there but I suspect the error you’re seeing on screen comes from an error being raised. You could try using case… with {:ok, result} and {:error, error} tuples or try to trap the error if it’s from a raise. I thought that’s supposed to only happen with the functions with ! on the end though. You should be able to inspect at the boundary you’re at to get some insight over just a 400 response.
If this were me and that all didn’t work then I’d start unpacking what deliver did with more inspect calls or essentially what you said. I don’t always try to peel back a library’s stack traces unless I think I’ve exhausted what I can at the outer most layers. Bad requests don’t usually come from erroneous data, it usually comes from sending a GET where a POST is necessary. Not all APIs are like that though. Sometimes a missing header or something random triggers it too.
Popular in Questions
Other popular topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Enabling companies to succeed by building software people love.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking for Elixir devs who love to ship. Start your free account.
Practical resources that improve the lives of professional developers.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"