Enable function to be created outside of StartHandler. #192
Conversation
Codecov Report
@@ Coverage Diff @@
## master #192 +/- ##
======================================
Coverage 77.2% 77.2%
======================================
Files 18 18
Lines 636 636
======================================
Hits 491 491
Misses 104 104
Partials 41 41
Continue to review full report at Codecov.
|
Super curious about your use-case! I suppose your plan also includes calling |
It's not all that interesting - we're using a custom logger for use with localstack on our development machines and the messages from log.Fatal don't come through in a way that's immediately inspectable for us. The version we have right now simply returns an error instead of killing the process, and that error is handled by our application entrypoint. Although now that we've done this, we see that sometimes the bind call is trying to re-use the same port within the lambda container from a previous invocation of the function, so we may end up adding a small backoff to net.Listen. |
eg: logs like this?
Are you currently seeing this behavior? We recently deployed a change in the service to mitigate a similar sounding issue we saw in our own internal tests.
Gotcha. Out of curiosity, is this an OSS logging formatter like https://github.com/sirupsen/logrus, or is it something else? Is this something that could be solved by using https://golang.org/pkg/log/#SetOutput? |
|
Yes, those logs. It turns out that it was bad behavior on the part of localstack plus the image lambci/lambda:go1.x. It's an issue between the workflow between these two parts. Localstack issues a docker exec command into binary wrapping the lambda handler in the lambda:go1.x image. This image will start a new process for each invocation and kill it once the lambda function completes. This makes the container start a new listener on the same hard-coded port for each invocation, where they clash under any amount of concurrency. Rewriting the wrapper in that container solves our issue (and we're trying to push that fix upstream). I don't think this issue has anything to do with this SDK (although the visibility made possible by this change was nice).
It's using gomol.
There are lots of solutions, but we were using a TCP/JSON output logger to stream logs in real time via socat (and could then grep through it via jq). We come form an environment where we were using an ELK stack when our stuff was hosted out-of-cloud. |
|
Ah, guess I had missed the emphasis on the "local" bit. Thanks for bearing with the questions, we're always interested in the details of how our customers are developing applications. |
Function is useless outside of the lambda package as there is no way to create a function with a non-nil handler. I have need to, for example, change the error conditions from log.Fatal within the entrypoint, but not having access to a Function constructor stops me from writing a reasonable replacement in my application code.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.