Recurring scheduled events behavior

Hello, i’ve been trying to understand the recurring schedules events behavior but i find it inconsistent at times, specially when the recurring event repeats itself a couple of times, i do know that the recommended time for a schedule to be created and then executed is at least 5 minutes and i’ve ran tests using that configuration and got the same results; i ran a test logging the time every minute in a recurring schedule to show the warning i’ve been getting:

“(node:692) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 done listeners added to [HtmlReport]. Use emitter.setMaxListeners() to increase limit”

After i get this warning the recurring schedule usually gets inconsistent, sometimes stopping and sometimes logging information later than expected, the event does log the correct time, so that implies that the event is executed at the correct time but the logs are not. The real question is, is this behavior/warning to be expected? Maybe my handler is doing something unexpected or i’m doing something wrong.

This is the code i’ve been running for the tests. It’s a modified version of the marketplace-sample-apps\Freshworks-Samples\App-Development-Features\Serverless-Features\scheduled_events\scheduled_event_one_time that i found on the Freshworks GitHub.

SimpleLog function.

createSchedule function and handler.

SMI function.


Hi @Pavel_ACL,

Thanks for creating a detailed topic! This is a good observation. Let me try to replicate this from my end as well.

if possible, can you also run FDK in debug mode to obtain more information in the log ?

Although the logs might not be shown at the right time in the console, the execution ideally happens at the proper interval time controlled by the scheduler. In production accounts, you would ideally notice the logs and execution at the same. Let me know if you notice discrepancies in production as well

Hello @Hem i ended up running some more tests to verify if my code had bugs somewhere and if that was the cause of the problem, what i seem to notice is that for every event that is invoked from the server a listener is added to a same object wich is the event and that ends up causing low performance when i call the same event multiple times or even if more functions inside the server file get involved in the mix. At first i thought the problem was related to the code inside my server file, however, calling a function that only logs some text multiple times through SMI reproduces the same behavior.

I also ran my app using the debug mode but no relevant information about why the MaxListenersWarning occurs.

I even used the test code inside the documentation but the warning still keeps appearing, it seems like there’s an event getting created and being listened by multiple instances but not getting terminated, even when the renderData method is called.

Here’s a test using the documentation code that reproduces the bug.

Html app file

App.js file

Server.js file

And the console using the debug mode that shows the warning, the warning usually appears after i invoke the function through SMI 5 times:

I’ve been looking for a lot of options about this issue because it affects performance heavily when more server methods get involved, it might be my work environment, i will reinstall my S.O. just to discard that option, the FDK version i’m running currently is 6.2.7 since it seems to be a lo more stable regarding serverless performance. The node version i’m using is 10.18.0

Any and all information about this issue is greatly appreciated.

1 Like

As an update i did reinstall my S.O. to see if that could be the issue but it was not, however, i ran some more tests creating schedules and deleting them using SMI and returning data through the renderData(json) method, for whatever reason the server console (wich is the one showing the warning and the sluggish behavior) keeps getting stuck and doesn’t show the messages it should be displaying, however, once i started using the renderData method to return data to the SMI i observed on the client side console that the operations were being done in a timely manner, unlike what the server console suggested. I’ll keep on running tests to see if this behavior is consistent.