serverless: `serverless invoke local` returns exit status 0 when the handler code throws error

This is a Bug Report

Description

For bug reports:

What went wrong? sls invoke local -f exist exits with status 0 when invoke fails due to error in the handler code.

Note, the exit status is 1 (correct behaviour) when invoke fails before reaching the handler code. sls invoke local -f notExist

What did you expect should have happened? Exits with status 1.
What was the config you used?
What stacktrace or error message from your provider did you see?

For feature proposals:

What is the use case that should be solved. The more detail you describe this in the easier it is to understand for us.
If there is additional config how would it look

Similar or dependent issues:

#12345

Additional Data

Serverless Framework Version you’re using: 1.24.1
Operating System: macOS 10.13 / Ubuntu 16.04
Stack Trace:

ReferenceError: awefpohi is not defined
    at Object.<anonymous> (/Users/frank/Sites/Test/handler.js:3:1)
    at Module._compile (module.js:660:30)
    at Object.Module._extensions..js (module.js:671:10)
    at Module.load (module.js:573:32)
    at tryModuleLoad (module.js:513:12)
    at Function.Module._load (module.js:505:3)
    at Module.require (module.js:604:17)
    at require (internal/module.js:11:18)
    at AwsInvokeLocal.invokeLocalNodeJs (/usr/local/lib/node_modules/serverless/lib/plugins/aws/invokeLocal/index.js:251:33)
    at AwsInvokeLocal.invokeLocal (/usr/local/lib/node_modules/serverless/lib/plugins/aws/invokeLocal/index.js:125:19)
    at AwsInvokeLocal.tryCatcher (/usr/local/lib/node_modules/serverless/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/usr/local/lib/node_modules/serverless/node_modules/bluebird/js/release/promise.js:512:31)
    at Promise._settlePromise (/usr/local/lib/node_modules/serverless/node_modules/bluebird/js/release/promise.js:569:18)
    at Promise._settlePromise0 (/usr/local/lib/node_modules/serverless/node_modules/bluebird/js/release/promise.js:614:10)
    at Promise._settlePromises (/usr/local/lib/node_modules/serverless/node_modules/bluebird/js/release/promise.js:693:18)
    at Async._drainQueue (/usr/local/lib/node_modules/serverless/node_modules/bluebird/js/release/async.js:133:16)
    at Async._drainQueues (/usr/local/lib/node_modules/serverless/node_modules/bluebird/js/release/async.js:143:10)
    at Immediate.Async.drainQueues [as _onImmediate] (/usr/local/lib/node_modules/serverless/node_modules/bluebird/js/release/async.js:17:14)
    at runCallback (timers.js:773:18)
    at tryOnImmediate (timers.js:734:5)
    at processImmediate [as _immediateCallback] (timers.js:711:5)

Provider Error messages:

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 10
Comments: 22 (11 by maintainers)

Commits related to this issue

#4852 fix by rethrowing a module loading exception in aws invoke local — committed to GuruRAM/serverless by GuruRAM 6 years ago
#4852 "should throw when module loading error" unit test improvement — committed to GuruRAM/serverless by GuruRAM 6 years ago
Merge pull request #4873 from GuruRAM/master serverless invoke local error handling fix for #4852 — committed to serverless/serverless by HyperBrain 6 years ago

Most upvoted comments

Hi @fwang , nice catch. I agree that errors in the handler itself should not be catched unconditionally and should be converted to a 1 exit code to let them check in automated ways.

HyperBrain on Mar 27, 2018

Has this been resolved?

dsmileyephe on May 30, 2019

does anyone is having the same issue using serverless invoke test ?, I’m having issues with this on AWS code deploy, beacuase it does not exits before call the deploy command.

edmret on Apr 11, 2019

@dschep @shortjared I didn’t have time to come up with a good overall fix for the issue but I was able to narrow down to where the issue lies. Something like this works, at least for the python invoker

https://github.com/serverless/serverless/compare/master...Shaun1:master

I think the principle will be the same for other languages as well: the exitCode of the resolved invoker promise should be what the overall process exits with.

Shaun1 on Dec 14, 2018

@Shaun1 yeah, I don’ think this should’ve been closed.

dschep on Dec 14, 2018

What about this issue?

pirmax on Sep 18, 2019

Thanks @Shaun1, yeah it looks like it’l have to be implemented per language.

dschep on Dec 14, 2018