Issue Overwriting Environment Variables about serverless-plugins

[esetnik]

@godu I think this should be reopened. serverless-offline is now recommending the use of --useWorkerThreads for node v11.7+ dherault/serverless-offline#508 (comment) because there's no way to debug when using --useSeparateProcesses, however --useWorkerThreads doesn't work with serverless-offline-sqs in that the process.env is still wrong for the function despite being launched in a separate worker thread.

[pauldprice]

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?

[fusionbeam]

same here ...

[abby-huisman]

I'm encountering an issue related to this as well. Is there a plan to change this? If so, is there an ETA?

[godu]

Hi,

First of all, IMO, it's more a serverless-offline's bug than serverless-offline-{kinesis/sqs/dynamodb-stream}'s one.

Unfortunately, I think we need this kind of hack to avoid possible side-effects produce by some process.envs mutations.

I'll explain.

AWS Lambda allow us to defined different environment variables by lambda. However, serverless-offline, by default, execute all lambdas in the same thread, and share, in the facts, the same process.env value.

By example, imagine two lambdas lambda-red and lambda-blue :

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 --useSeparateProcesses options to isolate lambda's execution's context.

I think a good practice is to extract environment variables in the root scope, due to the process.env's immutability property that should have.

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.

[thetumper]

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.