-
Notifications
You must be signed in to change notification settings - Fork 133
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
Issue Overwriting Environment Variables #20
Comments
The code is messing with process.env before calling the handler and then it changes it back after the handler is invoked. However, if you have any async code that is called by the handler then that code may run after process.env is set back. I'm running into this same issue and am wondering why process.env should be reset? |
same here ... |
I'm encountering an issue related to this as well. Is there a plan to change this? If so, is there an ETA? |
Hi, First of all, IMO, it's more a Unfortunately, I think we need this kind of hack to avoid possible side-effects produce by some I'll explain. AWS Lambda allow us to defined different environment variables by lambda. However, By example, imagine two lambdas functions:
lambda-red:
handler: handler.color
environment:
COLOR: red
lambda-blue:
handler: handler.color
environment:
COLOR: blue with the same handler : module.exports.color = (event, context, color) => {
console.log(process.env.COLOR);
setTimeout(() => {
console.log(process.env.COLOR);
cb();
}, 1000);
}; If we trigger both in the same time, we got this output: lambda-red: red
lambda-blue: blue
# 1s later
lambda-red: blue
lambda-blue: blue A solution is to use I think a good practice is to extract environment variables in the root scope, due to the const {COLOR} = process.env;
module.exports.color = (event, context, color) => {
console.log(COLOR);
setTimeout(() => {
console.log(COLOR);
cb();
}, 1000);
}; I'm open for suggestion. Maybe there is another solution. |
@godu I think this should be reopened. |
Any chance to get a workaround or fix for those who cannot move to node v11.7+? I've been looking at other options, but have not found any simple alternative. |
What is the purpose of overwriting process.env on line 138? I've been wrestling with a pretty nasty bug for the last few days and traced it down to this single line of code. When I comment it, the function environment is preserved as defined in serverless.yml, but when I leave it uncommented, I lose all environment variables defined under provider.environment.
Some feedback would be appreciated. This is a project for a very large client and I'd love to use the plugin. It is working well otherwise with ElasticMQ running locally.
https://github.com/godu/serverless/blob/589ee1901d68f39f71a6e61682aa28018554f0be/packages/serverless-offline-sqs/src/index.js#L138
The text was updated successfully, but these errors were encountered: