A few questions on various "limits" with freshservice serverless apps

Hello all,

I submitted a support request for this but I guess that’s not the right channel for these questions so trying here. If anyone can answer any of these it would be greatly appreciated.

copy/paste of my original ticket begins here (I should note this is all in the context of custom apps only for our tenant, not deployed to the marketplace):

I have a few questions regarding using the FDK to create custom serverless apps.

Reference:

https://developers.freshworks.com/docs/app-sdk/v2.3/freshservice/serverless-apps/

  1. From doc: “The serverless apps are run in the sandbox mode. Therefore, usage of methods such as process, buffer, clearImmediate, clearInterval, clearTimeout, setImmediate, setInterval, and setTimeout in the app logic is not supported.”

setTimeout is a common method to create a blocking “pause” in the program flow, with that not being available, is there a feature in the framework I’m not finding to be able to introduce a “pause”? We need to detect rate limits, such as with your “request” api which will return a 429 code in the error object when exceeded. In this case, the app logic needs to pause, and retry. How then do we pause? (I’ve created and tested a “time” based approach but it’s really not a good way to simply pause, as it wastes cpu cycles). Does the framework provide another mechanism to handle this common need? We must detect a rate limit, pause, and retry. Is there no pause, but rather we are supposed to use the schedule feature and schedule a retry of the function x seconds in the future maybe?

1a. The “request” api throws an exception when the limit is breached and includes the 429 code in the error object, however the headers are empty, there is no “Retry-After” value as there is if you were to call the freshservice api directly. Why is this not included in the error thrown by “request”, it does have the “headers” field in the object, but it’s empty.

Reference:

https://developers.freshworks.com/docs/app-sdk/v2.3/freshservice/serverless-apps/product-events/

  1. From doc: “The default app execution timeout is 20 seconds. If the request timeout is increased to 20, 25, or 30 seconds, the app execution timeout is extended to 40 seconds.”

How exactly do I make this change? I want to increase the app execution timeout to 40 seconds.

2a. What exactly happens when this timeout is reached? How can I know when this happens?

Reference:

https://developers.freshworks.com/docs/app-sdk/v2.3/freshservice/smi-apps/

  1. From doc: “The rate limit for the serverless component is 50 triggers per minute.”

This is from the smi-apps section of the docs, however I assume it applies to all serverless apps. Please let me know if that’s not the case. So what exactly happens on the 51st trigger? How can I know when this happens? Can it be increased?

Really hoping for some answers so I can make some final design decisions. Assuming I can increase my execution timeout to 40 seconds my biggest “potential” blocker may be the 50 trigger per minute limit on the serverless function. I don’t think we would be hitting that limit under normal circumstances but there could be other bulk/automated things that happen by others that could spike it, so I need to plan/design for that possibility.

1 Like

Hello @David_Copenhaver, I wish I could be more help here, but I will tag a few individuals who I think will be able to get you some answers.

@Saif and @zach_jones_noel could you help David out here? I would be interested to see how the platform handles these scenarios that he is questioning.

Thank you!

Hey @David_Copenhaver,
Welcome to the Freshworks developer community! :tada:

One way to handle the rate limits is with a request template defined with retryDelay and maxAttempts where the platform will automatically retry after the set delay and also ensure it retries based on the configuration. Request template configuration docs.
And about the headers not present will check that up.

For request timeout increase, you can raise a ticket to us via dev-assist ticket.

SMI has a rate limit of 50 RPM and at 51st invocation, you would get a 429 error where we can increase that again with a dev-assist ticket to increase rate limits

The rate limit or request timeout increase is on a case-by-case basis, you can refer this - Get assistance in extending platform rate limits for your apps for more details on how to request and default rate limits.

Thanks Zachary, much appreciated.

Thanks zach_jones_noel, I can see where this could be used in certain situations. I appreciate the info.

Thanks zach_jones_noel, once again :slight_smile:

  1. For requesting rate limit increases via the dev-assist portal, does that apply to custom private apps only in our own tenant as well? I wasn’t sure if maybe that was only for marketplace apps.

  2. Regarding what happens on trigger 51, I’m not sure if there is a specific difference between calling the serverless function in an SMI app (calling from a front end app) versus just having a serverless app listening for particular events to trigger on. In my case, it’s the latter, just a serverless app listening to certain events. What I’m seeing in my logs (and I’m logging every logic path and any errors specifically to observe the behavior), I just see all logs stop after 50, no output in logs, not errors in logs, no 429, nothing. Is that because there is difference between this behavior for SMI apps calling serverless functions versus a serverless app triggering functions on events?

Thanks again! Your input is much appreciated.

Hi David,

Hope you are doing well.

The portal has options for both Private and Public apps. Following is a screenshot for reference,

I was working on a serverless application where I have seen the below error in logs whenever I have exceeded the per minute limit for Request methods,

{status: 429, message: "You have exceeded the limit of 50 requests per minute", errorSource: "APP"}

1 Like

Hey @Pulkit_Chowdry,
Thanks for sharing it.

Hey @David_Copenhaver,

Curious to understand this behavior. Ideally, when you hit the rate limit like @Pulkit_Chowdry mentioned, you should find an error with error code 429, but the invocations and logs should show up the next min onwards.

For serverless apps with product events, when the code in server.js makes request method invocations, 50 is the default rate limit where any invocation more than 50 per minute would error with 429 and that should be logged. Still, when SMI is invoked from the front-end (app.js) which breached the default rate limit, that would get 429 errors.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.