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

Dedicated handling of AWS Lambda environment #475

Closed
wants to merge 1 commit into from

Conversation

medikoo
Copy link
Contributor

@medikoo medikoo commented Jul 17, 2017

Recently I'm working with projects that stand on Serverless architecture (AWS Lambda), and found that debug doesn't play well with that.

Thing is that in AWS Lambda ( http://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-logging.html ) all console.* methods are internally decorated, so then all logs are combined with meaningful info on time and invocation id), so outcome of console.log("this is console log"); etc. ends as:

screen shot 2017-07-17 at 11 48 42

Now debug (as run at v2.6.8) by defaults logs as:

screen shot 2017-07-17 at 11 49 52

This patch ensures that eventual debug in case of being run in AWS Lambda outputs logs via console.error therefore comes out as following:

screen shot 2017-07-17 at 11 51 47

@coveralls
Copy link

coveralls commented Jul 17, 2017

Coverage Status

Coverage decreased (-0.7%) to 63.095% when pulling b80437c on medikoo:aws-lambda-friendly into a45d4a0 on visionmedia:master.

@medikoo
Copy link
Contributor Author

medikoo commented Jul 17, 2017

Coverage decreased (-0.7%)

I can configure some tests that try to emulate AWS Lambda env, and run basic tests, but it may need some sophisticated handling in a module (e.g. module cache invalidation). Let me know

@coveralls
Copy link

coveralls commented Aug 9, 2017

Coverage Status

Coverage increased (+0.9%) to 73.585% when pulling 196d518 on medikoo:aws-lambda-friendly into 13e1d06 on visionmedia:master.

@medikoo
Copy link
Contributor Author

medikoo commented Aug 9, 2017

Updated for v3

@medikoo
Copy link
Contributor Author

medikoo commented Aug 21, 2017

Closing this, for following reasons:

  • After Use Date#toISOString() instead to Date#toUTCString() when output is n… #418 got in, the default output differs only in not having invocation id. which is not that relevant, as there's no concurrency within single lambda in CloudWatch we can clearly deduct which invocation id applies to which debug line).
  • It's too custom, which seems bad to have hard-coded in. it's best if addressed by external tweaking, which probably is doable now and if not, should be after major overhaul is done.

@medikoo medikoo closed this Aug 21, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants