Strange behavior of `onTicketUpdate` event in Freshservice Sandbox

I have built a custom severless app that sends a notification to a third party Chat application called Fuze. I am using the onTicketCreate, onTicketUpdate, and onConversationCreate events. Both the onTicketCreate and onConversationCreate events work by sending a single notification to the chat app. However, the onTicketUpdate event is duplicating itself and running twice, sending two notifications.

When I look at the serverless logs it shows the event being triggered twice regardless of what properties I change on the ticket. For example, I will change the source and click update on the ticket details page, and this will trigger the onTicketUpdate event twice according to the logs, and the fact that I get two notifications in the third party chat application.

Anyone else having this issue?

Hi Zachary,

I tried this in my Fservice and it seems that there is only one event triggered per property update. Can you also check if you make any property updates in onTicketUpdateHandler? That in turn might trigger another event. Try to provide the server.js file also. I will have a look

Hello @shravan.balasubraman, Below is the code that I am using. I don’t see where I would be triggering a second event. All we are doing is triggering a notification to be sent using a post request. Thank you for looking into this for me.

 const axios = require('axios').default;

exports = {
	events                : [
		{
			event    : 'onTicketCreate',
			callback : 'onTicketCreateHandler'
		},
		{
			event    : 'onTicketUpdate',
			callback : 'onTicketUpdateHandler'
		},
		{
			event    : 'onConversationCreate',
			callback : 'onConversationCreateHandler'
		}
	],

	// args is a JSON block containing the payload information.
	// args['iparam'] will contain the installation parameter values.
	onTicketCreateHandler : function (args) {
		console.log('Ticket Created');
		console.log(args);
		if (args.data.ticket.custom_fields[0].value !== null) {
			axios({
				method           : 'post',
				url              :
					'https://api.fuze.com/chat/v2/webhooks/incoming/apiKey',
				headers          : {
					'Content-Type' : 'text/plain'
				},
				transformRequest : [
					(data) => {
						let ticketSubject = JSON.stringify(args.data.ticket.subject);
						let majorIncidentType = JSON.stringify(
							args.data.ticket.custom_fields[0].value
						);
						let ticketID = JSON.stringify(args.data.ticket.id);
						data =
							`Ticket ${ticketSubject} has been identified as a ${majorIncidentType}. Please follow the link below to view the ticket.` +
							'\n' +
							'https://cedservicedesk-fs-sandbox.freshservice.com/helpdesk/tickets/' +
							ticketID;
						return data;
					}
				]
			});
		}
	},

	onTicketUpdateHandler : function (args) {
		console.log('Ticket Updated');
		console.log(args);
		if (args.data.ticket.custom_fields[0].value !== null) {
			axios({
				method           : 'post',
				url              :
					'https://api.fuze.com/chat/v2/webhooks/incoming/apiKey',
				headers          : {
					'Content-Type' : 'text/plain'
				},
				transformRequest : [
					(data) => {
						let ticketSubject = JSON.stringify(args.data.ticket.subject);
						let ticketID = JSON.stringify(args.data.ticket.id);
						let status = JSON.stringify(args.data.ticket.status_name);
						data =
							`Ticket ${ticketSubject} has had it's ticket properties updated. It's current status is ${status}. Please follow the link below to view the ticket.` +
							'\n' +
							'https://cedservicedesk-fs-sandbox.freshservice.com/helpdesk/tickets/' +
							ticketID;
						return data;
					}
				]
			});
		}
	},

	onConversationCreateHandler : function (args) {
		console.log('Note or Reply Added');
		console.log(args);
		let ticketID = JSON.stringify(args.data.conversation.ticket_id);
		let url = 'https://cedservicedesk-fs-sandbox.freshservice.com/api/v2/tickets/' + ticketID
		let apikey = 'XXXXXXXXXXXXX';
		axios({
			method:'get',
			url,
			auth: {
				username: `${apikey}`,
				password: 'X'
			}
		})
			.then((response) =>{
			console.log(response.data.ticket.custom_fields.major_incident);
			let isMajorIncident = response.data.ticket.custom_fields.major_incident;
			if (isMajorIncident !== null) {
				axios({
					method           : 'post',
					url              :
						'https://api.fuze.com/chat/v2/webhooks/incoming/apiKey',
					headers          : {
						'Content-Type' : 'text/plain'
					},
					transformRequest : [
						(data) => {
							let ticketSubject = JSON.stringify(response.data.ticket.subject);
							let ticketID = JSON.stringify(response.data.ticket.id);
							data =
								`A new comment has been added to ticket ${ticketSubject}. Please follow the link below to view the ticket.` +
								'\n' +
								'https://cedservicedesk-fs-sandbox.freshservice.com/helpdesk/tickets/' +
								ticketID;
							return data;
						}
					]
				});
			}
		}).catch(function (error) {
			console.log(error);
		});
	}
};

Hi @shravan.balasubraman,

Any updates on this? Did the code I provide help identify why this might be happening in my instance of the freshservice sandbox?

@Zach,

Does this happen when you try to simulate onTicketUpdate event during your local testing?

@Zach Can you also check if this happens in any other Fservice accounts? I have tried in two accounts and is not reproduceable

Hello @Saif and @shravan.balasubraman, I have only been able to test this in our freshservice sandbox environment. I don’t want to install it into production until I know it is good to go.

In the sandbox environment I have had this anomaly happen when simply local testing, as well as after I package the app and install it through the developer portal into our sandbox.

Hope this clears things up. Thank you for looking into this for me.

Hi @Zach, Can you try to upload the custom app in the non sandbox account. Will that be a problem. If no, please ensure if the same happens there. Meanwhile let us look into why this happens in sandbox env.

Hello @shravan.balasubraman, due to the nature of this app we cannot install and test in the production environment without disruption and alerting of stakeholders. Perhaps this is just an issue with the sandbox environment. But its risky for me to push this to production without first ironing out the details in our sandbox.

I see you were able to see this occurrence in local testing.

Can you switch to the debug mode and share the logs with us when this issue is occured?

Also, is this issue blocking any of your current work?

Hello @Saif,

I have created another application that requires creating a Fuze notification similar to the above scenario. I went ahead and built it and installed the application in the Production Environment, thinking maybe it is just a bug in the sandbox environment but I am still having weird behavior even from production.

I will try to explain…The application utilizes onTicketCreate, onTicketUpdate, and onConversationCreate.
I created a ticket, and from the new ticket page, I filled out my fields and made sure to include the required group that would trigger my if statement to then send the notification to fuze.
This caused 2 notifications, 1 for ticket creation, and 1 for ticket updated and they appeared in the incorrect order with the update notification appearing first

Then I simply updated the status of the ticket to “Pending”, this triggered 2 more notifications but this time they were duplicates of eachother, as if the onTicketUpdate was sent twice.

Lastly I added a note to the ticket and that triggered the onConversationCreate notification with one notification just like it was intended to work.

So I am not sure what is causing the double notification at ticket creation, and the duplicated notifications for onTicketUpdate.

Any help you can offer would be greatly appreciated, as I need these notifications for a few of our stakeholders.

Thank you,

Zach

Thanks for taking up the effort and explaining it @Zach.

Let me first check if there is some discrepancies from the app platform’s end. Is it possible for you to recall the range of date and times when you saw this behaviour happen?

Is it only those dates and timings when this incident occurred, or does it happen every-time when those product events are triggered?

Hi @Saif,

This is a recurring problem in both the sandbox and the production environment. I have been testing this application throughout the build process all last week. The issue presented itself originally, at the same time this original post was created. So back on May 22nd. I stopped working on the original application because I was not able to test in the production envrionment as one of the steps in troubleshooting that you mentioned in the above thread. This time I took the risk and installed into production to see if the problem existed in that environment and it does.

Hope this helps. We really could use both of these applications as soon as possible.

Thank you for your help looking into this issue.

-Zach

Hi @Saif

I received your response regarding this issue in my email, but don’t see your response in this thread. However, just so I understand correctly, another user was experiencing something similar and the issue was identified due to a ticket automation that would run after the ticket was created, updating ticket properties. Therefore, triggering the “onTicketUpdate” event? I mean this makes sense and I can’t believe I didn’t think of that as a potential issue.

That being said, I have a number of ticket workflows that make changes to tickets after they are created. How would you suggest I move forward to obtain my desired result of being able to isolate the onTicketUpdate event only being triggered by an agent and not by a workflow? Cuz, I would hate to lose the functionality of the onTicketUpdate event for my current and future custom applications.

Thank you for your time and support with this issue. I know it has been a challenging one.

-Zach

1 Like

Yes @Zach,

I have written an early reply and later deleted it because I needed to confirm couple of things to share accurate response. Looks like forum was smart that it triggered an email very fast :racehorse:

So, here is what I learnt Zach,

  • If there was a workflow configured on ticket property update.
  • For example, there is a workflow configured that updates Priority when ever status is updated. That means product sees two updates of it’s ticket properties and tell your app the same. Which is why app senses 2 triggers.

While that is at the core of the problem, I am also looking for a solution.

From what I digged down and found out, all the product level events performed will have a special attribute (For example, event_id to be 0). At this point I am trying to learn from @Anand_Ganesan, who had a similar problem to find what those exact attributes are. The idea is, if those attributes are known, app can filter out product-level events and disallow duplicates.

2 Likes

I learnt that every Freshservice product event like ticket create/update or note create would have a following attribute,

"actor":{
    "profile_id":0
}
  • "profile_id" refers to the user ID of the user who is performing the action.
  • On Web, current user ID
  • Scenario Automation: Current user ID
  • Workflow Automator: it’s 0
  • Via APIs - User ID of the user whose API key is used
2 Likes

This topic was automatically closed after 14 days. New replies are no longer allowed.