SMI application runs locally but not on platform

App Platform
, , , ,
1

Good afternoon,

I am hoping someone may be able to shed light on how I can further diagnose SMI application issues.

We have developed a custom application that will be ready for testing shortly (not for public use). The application runs as expected using fdk run and SMI endpoints are working correctly. We are using the same iparams locally as we are inside the platform, but are facing the following 500 server error issue.

errorSource: "APP"
message: "Error while executing the app server script."
status: 500

We have logging both before and after an invokeTemplate, so I have narrowed it down to this, but we see no other errors in the SMI application log that tells us why that particular invokeTemplate actually failed (no custom stdout logging is seen in the logs directly after the try/catch block, .catch() promise handling etc). We tried hard-coding the iparams to no avail. Note, the SMI endpoint successfully returns if I remove the invokeTemplate.

To explain the behaviour, it seems that the process is simply crashing, as I would expect something/anything from invokeTemplate; it fails after 4-5s.

We have other invokeTemplates in the application that seems to be working fine.

I understand it’s sandboxed so inspecting any node logs further upstream on the Freshworks platform is probably not going to be possible from my end.

Also to note, this same application was functioning correctly around 2 weeks ago as we were demo’ing it to our internal stakeholders.

Previous demo version was running on node 24.11.0 and fdk engine 10.0.0.

This version is running on node 24.11.0 and fdk engine 10.1.0.

I have also tested this version on 24.11.0 and fdk engine 10.0.0 without success.

Thank you in advance.

2

This topic can be closed now. The issue has seemingly resolved itself.

3

Unfortunately the issue has presented itself again. The intermittent behaviour suggests something else may be happening.

Is there a possible way to see if there’s rate limits being exceeded or outward requests being blocked?

4

Further diagnostics show that the SMI application started working after a Fresh event came in (onTicketCreate in this case). The SMI application could then start making outbound calls using invokeTemplate.

I have also observed $db.get would throw a 404 when attempted to be used before the SMI application started ingesting events (onTicketCreate). After a onTicketCreate event, $db.get started working and outbound calls could be made. I understand $db is context aware which is something we’d accounted for.

Is this a potential bug?

5

We’ve noticed that $db seems unreliable and is not working as intended for our use case.

For example:

// note: log & error are functions that call to console.log and console.error respectively

log(`onScheduledEvent re-scheduled in the next ${frequency.toFixed(2)} minutes`, access_token)

await $db.set(“bearer”, { access_token }).then(log, error).catch(error)

log(“Token successfully retrieved”, access_token)

We never see “Token successfully retrieved” nor any errors stemming from the $db API; the widget that resides at ticket_sidebar simply receives a 500 error.

This has led us to believe there’s something going on with $db itself which is not surfacing in the logs.

We’ve since had to remove our reliance on this unfortunately.

6

Hey Michael,

Can you please share the App ID for this custom app and the org URL via direct message here on the community?