Ive been chasing down a Jira to Spira sync issue now for weeks, months even. In the last week I have spent at least three full days work on it. Most of that time is wasted time caused by Spiras event logs failing to provide the crucial information required to identify the EXACT nature of the problem AND communicate it clearly to Spira support. Its wasting all our time...not just mine. Ive been in the IT game since the early 1980s and I am still surprised by how poorly exception handling and logging is done most of the time. As mentioned the problem I am having is that the Spira to Jira BUG/ISSUE sync is not working. Ive got a long way do the path. Most things are happening but I am still getting two errors in the log every time something changes (I will include details later). These arent trivial issues for me. Data is being clobbered and as a result I cant trust the process AT ALL at the moment. Details aside, for Spira to be getting an error on a synchronisation, I would expect it to be comparing one or more things/fields to in fact even know theres an error? So why not tell us, exactly, what they are? Because the event log simply DOESNT tell us which FIELD and WHAT data (on either side of the sync) is causing the error. Why not? Laziness is my guess. Some programmer has said This will never happen. Lets just dump it to the log...and here we are. Im not asking for help or answers to my problem here. This post is about getting better event log messages. So with that in mind below is just one of the errors I get that is a) enormous and b) almost completely unhelpful. Heres one of the errors: ErrorData SynchronizationError Updating SpiraTeam Incident to JIRA: Web Exception Error calling JIRA REST API: The remote server returned an error: (400) Bad Request. Details: {errorMessages:[],errors:{rankBeforeIssue:expected Object,rankAfterIssue:expected Object}} ...and heres its details... Error Updating SpiraTeam Incident to JIRA: Web Exception Error calling JIRA REST API: The remote server returned an error: (400) Bad Request. Details: {errorMessages:[],errors:{rankBeforeIssue:expected Object,rankAfterIssue:expected Object}} Error Updating SpiraTeam Incident to JIRA: Web Exception Error calling JIRA REST API: The remote server returned an error: (400) Bad Request. Details: {errorMessages:[],errors:{rankBeforeIssue:expected Object,rankAfterIssue:expected Object}}at Inflectra.SpiraTest.PlugIns.JiraCloudDataSync.JiraClient.JiraManager.RunQuery(JiraResource resource, String argument, String data, String method)at Inflectra.SpiraTest.PlugIns.JiraCloudDataSync.JiraClient.JiraManager.SaveIssue(JiraIssue jiraIssue, Boolean statusChanged)at Inflectra.SpiraTest.PlugIns.JiraCloudDataSync.DataSync.ProcessUpdatedIncident(Int32 projectId, SoapServiceClient spiraImportExport, RemoteIncident remoteIncident, List`1 newReleaseMappings, Dictionary`2 customPropertyMappingList, Dictionary`2 customPropertyValueMappingList, RemoteCustomProperty[] incidentCustomProperties, RemoteDataMapping[] incidentMappings, JiraProject jiraProject, JiraManager jiraManager, String productName, RemoteDataMapping[] severityMappings, RemoteDataMapping[] priorityMappings, RemoteDataMapping[] statusMappings, RemoteDataMapping[] typeMappings, RemoteDataMapping[] userMappings, RemoteDataMapping[] releaseMappings, RemoteDataMapping[] incidentComponentMappings, List`1 recentlyUpdatedFromJira)at Inflectra.SpiraTest.PlugIns.JiraCloudDataSync.DataSync.Execute(Nullable`1 lastSyncDate, DateTime serverDateTime) Ive looked at hundreds of messages like this, in Spira, for this problem. Other people, including Spira support, have looked at these messages...a lot. So I have reasonable confidence that this isnt just me. No-one can point me in the right direction. Ive been going around and around. So, in the Event logs, Why cant we see: 1) A date and time stamp in the details (because when you view the details among this many events it is hard to tell which one you are looking at) 2) The field names that caused the error? Ive looked and looked. I cant see that information. There are things named, but they seem irrelevant. 3) The actual data that caused the error? Really? Just why-the-hell-not? If I could enter unique and identifiable data in bug fields I could see which one was at fault but... 4) Why not report an IDs of the records, or BUGS/Incidents etc. The data must be there at the syncs fingertips to be able to know theres a problem. Just fricken tell us!! 5) Which direction the data was trying to go? With the lag in the sync process itself and the subsequent logs it is quite annoying to not be able to just see in the log which directions was at fault. Ive had to derive this information from hours of changing one thing and waiting for at least three minutes to see what happens...and even then things get logged a few minutes after I expect them to be. These are just 5 things off the top of my head that would make Spiras event logs not just better, but actually useful. Heres another idea to make event logs better... perhaps make the amount of detailed displayed in the log adjustable - less for everyday, more for when troubleshooting. I realise that when dealing with third party products things can be out of Spiras and my control. My issue may well come down to something I cant change in Jira. These logs, and many of the things Spira USERS are required to do to make this Sync work, fail to realise that many of us live within the constraints of IT departments with access policies of their own. They deny us what Spira tells us we need AND are slow, unresponsive and intractable in themselves. Information is power. If Spira and Spira support think it isnt their fault, then show us the information. Give us event logs that log useful information...for US, the USERS/victims of all this. en-US(C) Copyright 2006-2026 Inflectra Corporation.support@inflectra.com/Computers/Software/Project_Management//Computers/Software/Quality_Assurance/KronoDesksupport@inflectra.comhttp://www.inflectra.com/kronodesk/forums/threads120/Support/Forum/announcements/rants-raves/2868.aspxthreadId=2868David L Moore (david@ihatemypc.com.au) Ive been chasing down a Jira to Spira sync issue now for weeks, months even. In the last week I have spent at least three full days work on it. Most of that time is wasted time caused by Spiras event logs failing to provide the crucial information required to identify the EXACT nature of the problem AND communicate it clearly to Spira support. Its wasting all our time...not just mine. Ive been in the IT game since the early 1980s and I am still surprised by how poorly exception handling and logging is done most of the time. As mentioned the problem I am having is that the Spira to Jira BUG/ISSUE sync is not working. Ive got a long way do the path. Most things are happening but I am still getting two errors in the log every time something changes (I will include details later). These arent trivial issues for me. Data is being clobbered and as a result I cant trust the process AT ALL at the moment. Details aside, for Spira to be getting an error on a synchronisation, I would expect it to be comparing one or more things/fields to in fact even know theres an error? So why not tell us, exactly, what they are? Because the event log simply DOESNT tell us which FIELD and WHAT data (on either side of the sync) is causing the error. Why not? Laziness is my guess. Some programmer has said This will never happen. Lets just dump it to the log...and here we are. Im not asking for help or answers to my problem here. This post is about getting better event log messages. So with that in mind below is just one of the errors I get that is a) enormous and b) almost completely unhelpful. Heres one of the errors: ErrorData SynchronizationError Updating SpiraTeam Incident to JIRA: Web Exception Error calling JIRA REST API: The remote server returned an error: (400) Bad Request. Details: {errorMessages:[],errors:{rankBeforeIssue:expected Object,rankAfterIssue:expected Object}} ...and heres its details... Error Updating SpiraTeam Incident to JIRA: Web Exception Error calling JIRA REST API: The remote server returned an error: (400) Bad Request. Details: {errorMessages:[],errors:{rankBeforeIssue:expected Object,rankAfterIssue:expected Object}} Error Updating SpiraTeam Incident to JIRA: Web Exception Error calling JIRA REST API: The remote server returned an error: (400) Bad Request. Details: {errorMessages:[],errors:{rankBeforeIssue:expected Object,rankAfterIssue:expected Object}}at Inflectra.SpiraTest.PlugIns.JiraCloudDataSync.JiraClient.JiraManager.RunQuery(JiraResource resource, String argument, String data, String method)at Inflectra.SpiraTest.PlugIns.JiraCloudDataSync.JiraClient.JiraManager.SaveIssue(JiraIssue jiraIssue, Boolean statusChanged)at Inflectra.SpiraTest.PlugIns.JiraCloudDataSync.DataSync.ProcessUpdatedIncident(Int32 projectId, SoapServiceClient spiraImportExport, RemoteIncident remoteIncident, List`1 newReleaseMappings, Dictionary`2 customPropertyMappingList, Dictionary`2 customPropertyValueMappingList, RemoteCustomProperty[] incidentCustomProperties, RemoteDataMapping[] incidentMappings, JiraProject jiraProject, JiraManager jiraManager, String productName, RemoteDataMapping[] severityMappings, RemoteDataMapping[] priorityMappings, RemoteDataMapping[] statusMappings, RemoteDataMapping[] typeMappings, RemoteDataMapping[] userMappings, RemoteDataMapping[] releaseMappings, RemoteDataMapping[] incidentComponentMappings, List`1 recentlyUpdatedFromJira)at Inflectra.SpiraTest.PlugIns.JiraCloudDataSync.DataSync.Execute(Nullable`1 lastSyncDate, DateTime serverDateTime) Ive looked at hundreds of messages like this, in Spira, for this problem. Other people, including Spira support, have looked at these messages...a lot. So I have reasonable confidence that this isnt just me. No-one can point me in the right direction. Ive been going around and around. So, in the Event logs, Why cant we see: 1) A date and time stamp in the details (because when you view the details among this many events it is hard to tell which one you are looking at) 2) The field names that caused the error? Ive looked and looked. I cant see that information. There are things named, but they seem irrelevant. 3) The actual data that caused the error? Really? Just why-the-hell-not? If I could enter unique and identifiable data in bug fields I could see which one was at fault but... 4) Why not report an IDs of the records, or BUGS/Incidents etc. The data must be there at the syncs fingertips to be able to know theres a problem. Just fricken tell us!! 5) Which direction the data was trying to go? With the lag in the sync process itself and the subsequent logs it is quite annoying to not be able to just see in the log which directions was at fault. Ive had to derive this information from hours of changing one thing and waiting for at least three minutes to see what happens...and even then things get logged a few minutes after I expect them to be. These are just 5 things off the top of my head that would make Spiras event logs not just better, but actually useful. Heres another idea to make event logs better... perhaps make the amount of detailed displayed in the log adjustable - less for everyday, more for when troubleshooting. I realise that when dealing with third party products things can be out of Spiras and my control. My issue may well come down to something I cant change in Jira. These logs, and many of the things Spira USERS are required to do to make this Sync work, fail to realise that many of us live within the constraints of IT departments with access policies of their own. They deny us what Spira tells us we need AND are slow, unresponsive and intractable in themselves. Information is power. If Spira and Spira support think it isnt their fault, then show us the information. Give us event logs that log useful information...for US, the USERS/victims of all this. Tue, 14 Nov 2023 01:40:58 -05002026-02-26T07:17:10-05:00/Support/Forum/announcements/rants-raves/2868.aspxmessageId=6228David L Moore (david@ihatemypc.com.au) Here are some more real examples from my Spira System Event log; -- Unable to locate requested user Nothing -- Unable to locate mapping entry for Jira user 63f2fb17ce6f37e5ed92b83b so ignoring the assignee change Unable to locate mapping entry for Jira user 63f2fb17ce6f37e5ed92b83b so ignoring the assignee change -- Object reference not set to an instance of an object. In APPLICATION.Web.UserControls.WebParts.MyPage.PendingTestRuns::grdSavedTestRuns_RowCommand:Messages:Object reference not set to an instance of an object. [System.NullReferenceException {0x80004003}]Stack Trace:at APPLICATION.Web.UserControls.WebParts.MyPage.PendingTestRuns.grdSavedTestRuns_RowDataBound(Object sender, GridViewRowEventArgs e) -- Tue, 14 Nov 2023 03:03:09 -05002023-11-14T03:03:09-05:00/Support/Forum/announcements/rants-raves/2868.aspx#reply6228messageId=6229Clark R (simon.bor@inflectra.com) Thanks for taking the time to explain the issues you have had with our Jira data sync. I appreciate that it has been frustrating to resolve the sync issue and that it has taken a lot of your time. Hopefully our support team will be able to help get the specific problem you are facing resolved. Taking a step back, as you have done in this helpful post, error handling and logging is difficult to get right. As you say, it is, however, critical to troubleshooting - either for you as the end user or with our support team. Our data sync team tries to strike a balance between clear error messages and logging, without overwhelming users. In some areas we can definitely improve things, in others we have to rely on error messages from the third party application (in this case Jira). The team are working on an update to the Jira data sync that should be released this quarter. This updated will include a number of enhancements specifically related to logging. We will share this thread with them to see if there is anything more they can do based on your insights that will help you and other customers. Finally, I believe there are ways to increase the amount of logging to help with troubleshooting. This depends on how you are syncing with us. If you would like more help with that please contact our support team. Tue, 14 Nov 2023 13:51:30 -05002023-11-14T13:51:30-05:00/Support/Forum/announcements/rants-raves/2868.aspx#reply6229messageId=6530David L Moore (david@ihatemypc.com.au) Thanks Clark. At present I have had to give up on making the sync work the way wed like. Instead Ive had to develop a work-around and document it for my team (in-progress). Its far from ideal but Ive spent too much time on making this work when I need to be actually doing test activities for the project. David Sun, 19 Nov 2023 21:25:57 -05002023-11-19T21:25:57-05:00/Support/Forum/announcements/rants-raves/2868.aspx#reply6530messageId=6536Tasmania DoH (spiraplanadmin@health.tas.gov.au) Most of that time is wasted time caused by Spiras event logs failing to provide the crucial information required to identify the EXACT nature of the problem AND communicate it clearly to Spira support. Unfortunately, I have to agree. Currently my event log has hundreds of copies of the following message: Nullable object must have a value. In APPLICATION.Web.Services.Ajax.TasksService::Task_RetrieveProgress:Messages:Nullable object must have a value. [System.InvalidOperationException {0x80131509}]Stack Trace:at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)at APPLICATION.Web.Services.Ajax.TasksService.Task_RetrieveProgress(Int32 projectId, Nullable`1 releaseId) Hardly useful, and nobody seems to know what the issue is. Thu, 23 Nov 2023 04:09:17 -05002023-11-23T04:09:17-05:00/Support/Forum/announcements/rants-raves/2868.aspx#reply6536messageId=6537David J (adam.sandman+support@inflectra.com) That message means that when displaying a tooltip on the task progress bar, there was a null value. It is most likely a message that is logged and then caught and not displayed to the end user. So it can be ignored. Those messages are useful for our product team, but we have code in place to catch them and not cause an issue to the end user. Sun, 26 Nov 2023 21:02:05 -05002023-11-26T21:02:05-05:00/Support/Forum/announcements/rants-raves/2868.aspx#reply6537messageId=6538Frank V (frank.voelker@l7informatics.com) I also struggle to make sense of the context of the logs. context and better filtering controls would be a big help. Mon, 27 Nov 2023 18:46:14 -05002023-11-27T18:46:14-05:00/Support/Forum/announcements/rants-raves/2868.aspx#reply6538messageId=6547David L Moore (david@ihatemypc.com.au) Thanks for that John. Good to know (kind of) that Im not on my own and going mad. I must confess, I have also wondered why Spira upport dont have access to our logs? ...or maybe they do, but I feel I have had to spend a lot of time copy messages from the log into support tickets. It would nice to be able to just flag the messages in question, raise a ticket, and say refer flagged log messages. Most other systems Ive had the need to get help with have pretty much verified who I am and then gone straing to my instance of the thing and looked right at what I am seeing. Anyway, another one for the enhancements list. I am actually talking to Adam Sandman tomorrow morning :-) So 11 points out of 10 for escalation Spira. Ive been heard all the way to the top. Thanks. David Wed, 06 Dec 2023 05:27:28 -05002023-12-06T05:27:28-05:00/Support/Forum/announcements/rants-raves/2868.aspx#reply6547messageId=7152Craig Quintana (kindrabernier@hotmail.com) Thanks for sharing info. Tue, 18 Mar 2025 06:56:25 -04002025-03-18T06:56:25-04:00/Support/Forum/announcements/rants-raves/2868.aspx#reply7152messageId=7153Craig Quintana (kindrabernier@hotmail.com) This is useful for me. Tue, 18 Mar 2025 06:57:24 -04002025-05-07T09:43:46-04:00/Support/Forum/announcements/rants-raves/2868.aspx#reply7153messageId=7209gemma lyly (gemmalyly@gmail.com) If youve got specific examples of your current messages, toss them my way, and Ill tailor suggestions. For now, Ill lay out a framework and some solid replacements. Tue, 29 Apr 2025 07:09:17 -04002025-05-07T09:44:05-04:00/Support/Forum/announcements/rants-raves/2868.aspx#reply7209messageId=7231Katy Perry (katyperrykatyy@gmail.com) The adjustable detail level idea is brilliant too; a simple toggle for verbosity would save so much time. Wed, 07 May 2025 02:45:13 -04002025-05-07T09:44:14-04:00/Support/Forum/announcements/rants-raves/2868.aspx#reply7231messageId=7268Tom Woods (sayebi3988@dlbazi.com) Your suggestions for improving the event logs are spot on-having timestamps, specific field names, and the actual data that triggers errors. Tue, 27 May 2025 13:15:45 -04002025-05-28T07:32:09-04:00/Support/Forum/announcements/rants-raves/2868.aspx#reply7268