https://serverless-stack.com/ logo
Join Slack
Powered by
i have an ses:sendMail policy in my api stack that...
# help
a
i have an ses:sendMail policy in my api stack that works in the local dev environment, but doesn't work on prod...any idea why?
Copy code
new iam.PolicyStatement({
            actions: [
               "ses:sendEmail",
            ],
            effect: iam.Effect.ALLOW,
            resources: [
               "*",
            ],
         }),
i'm not even sure if it works or not, I just don't get an email in prod
and yes, my SES configuration is out of the sandbox
there is no error message for the lambda in cloudwatch
s
I would check CloudTrail, you should find details about permission error there
f
Yeah just to expand on @Slawomir Stec’s suggestion, you can also turn on AWS SDK logging, and see if the request is 200.
Copy code
AWS.config.logger = console;
You can also check the X-Ray. You can get the x-ray trace id from Lambda’s log.
a
can you set this up with serverless stack, or is it a manual thing?
i've put it into the utility that does the mail sending, and now I get 
[AWS ses 200 0.43s 0 retries] sendEmail({...
in the log of local dev environment, which is good
now to see where it goes to in prod environment
@Frank seems it needs additional configuration? Because simply adding that aws config didn't really do anything for the prod environment it seems. At least I don't see any new output in cloudwatch or xray
never mind the last message, i was able to set it up
so it seems the call to ses is fine, i get a 200 result...but it still doesn't send the mail
anyway, thanks for your help so far, I'm gonna see if I can get amazon ses specific help somewhere
seriously considering switching to mailgun or something right now
aaaaaaah, i think i got it
i forgot to await the sendMail call
strange, this somehow worked in local dev environment, but in prod, it probably killed the lambda before the promise was resolved
f
Hey @Adrian Schweizer thanks for the update. Glad you got it to work!
@thdxr, so Adrian ran into a situation where he didn’t 
await
on an AWS SDK call. It works on 
sst start
. Could it be that we wait for event loop to complete before we quit?
t
The process locally still runs even if you don't await it. In production the firecracker VM does more intelligent pausing (so AWS can fit more lambdas)
f
I vaguely remember in the old runtime server, we’d kill the process to ensure the behavior is consistent with live.
I see.. it’s pretty key we try to ensure the behavior is consistent… it there anything we can do here 🤔
t
I think anything we do would rollback the speed benefits we got from keeping the process around. Also technically there's no guarantee that your code doesn't still run even in prod
I did some experimenting at some point where I had background work executing on an interval and it still executed some of it before pausing the container
f
Ah right, that’s fair. I agree.. the prod behavior is actually not predictable.
a
Yeah, I actually got one mail through once in prod, before I added 
await
, as I can see in the bounce list. Was probably a friend who helped me testing when the environment wasn't warm.
I think it's one of the big pitfalls that everyone should be aware of, and frankly, they do tell you in several places about this behaviour. I'm just not the smartest guy around 🙂
f
lol who hasn’t gotten bitten by promises
Open in Slack
PreviousNext
Powered by