Issues when lambda has finished

[jaimesemp]

Hi,

I'm using this package with my aws lambda function.

I am having the next issue:

when lambda finished, some final logs are not printed. I can see them (the final logs) on the next lambda execution.

I guess this is due to submissionInterval and bottleneck.

Is there anyway that I can force/flush the pending logs overriding the submissionInterval behaviour?

thanks in advance

Btw great plugin!

[timdp]

Your analysis is correct. This is because logging happens asynchronously.

Winston v3 adds the finished event for this purpose. I haven't tried it out yet though.

In winston v2, I used to use a facade that would pass a callback to each call to winston. Winston would then call that callback when all transports had processed the log, and by keeping a count of pending logs, I could figure out if it was safe to end the process (or Lambda). As far as I can tell, the finished event (finally) makes this a lot easier.

[jaimesemp]

Thanks for the quick reply.

So... if I could manage the finished event, I would steel need to wait the submissionInterval time. Is there any way to force submission?

If that's not possible (and as I am a very ignorant person), would my lambda function performance would be very affected if I configure the submissionInterval to something very low (say for example, 50ms).

I know this is a little vague question, but could you give me some info/hints about that?

I could try the finished event and post my results here, but for that I would need to know if I can decrease the submissionInterval to something very low. Otherwise, I would need to use other logging solution (I dont want that my lambda function keeps waiting for logging to end if I can not decrease that time to something low... my app it is a chat app).

Thanks again

[timdp]

Sorry for not getting back to you earlier. I've unfortunately built up quite the backlog on GitHub.

When replying to #97 earlier, I claimed that I used to use this package myself with Lambdas, but I've actually just realized I haven't done that yet. I think you're probably right that the batch submission logic won't work great in serverless environments.

Reducing the interval to 50 ms seems dangerous. Not for performance of the Lambda itself, but you'll probably run into throttling at the AWS API level, depending on the concurrency of your Lambda.

Crazy thought though: what if you don't use this package at all and instead use the winston console transport? That will send your Lambda's logs to CloudWatch Logs regardless, which is also how I typically use Lambda. Or did you have a specific reason for using this package? For example, maybe you wanted to control the name of the log group/stream?