"api/V3/Projection/Commit", Random Error when trying to update projections..

Adrian_Paech

Hello,

We are using the Cireson "api/V3/Projection/Commit"  API call to update work items via Powershell.

This works perfectly 99% of the time, but occasionally, we get the following error (below) when attempting to commit changes.
Interestingly, if we copy the ticket exactly as it is, and then try to re-save it, it works fine, however, this is pretty painful, as we have to manually intervene when things go wrong.

I have attached the JSON code passed to "api/V3/Projection/Commit" which returns back the error shown below... hoping this helps to troubleshoot the issue.

Thanks in advance!

Adrian

{"success":false,"message":"An error occurred.","exception":"System.NullReferenceException: Object reference not set to an instance of an object.<br>at CiresonWebConsole.Controllers.api.V3.ProjectionController.d__5.MoveNext() in g:\\b\\7\\Portal\\RTMRel_SCSM2016\\src\\Cireson.WebConsole\\Cireson.ServiceManager.WebConsole\\Controllers\\api\\V3\\ProjectionController.cs:line 42<br>--- <br>End of stack trace from previous location where exception was thrown ---<br>&nbsp;&nbsp; at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)<br>&nbsp;&nbsp; at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)<br>&nbsp;&nbsp; at System.Threading.Tasks.TaskHelpersExtensions.d__3`1.MoveNext()<br>--- <br>End of stack trace from previous location where exception was thrown ---<br>&nbsp;&nbsp; at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)<br>&nbsp;&nbsp; at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)<br>&nbsp;&nbsp; at System.Web.Http.Controllers.ApiControllerActionInvoker.d__0.MoveNext()<br>--- <br>End of stack trace from previous location where exception was thrown ---<br>&nbsp;&nbsp; at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n&nbsp;&nbsp; at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)<br>&nbsp;&nbsp; at System.Web.Http.Controllers.ActionFilterResult.d__2.MoveNext()<br>--- <br>End of stack trace from previous location where exception was thrown ---\r\n&nbsp;&nbsp; at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)<br>&nbsp;&nbsp; at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)<br>&nbsp;&nbsp; at System.Web.Http.Filters.AuthorizationFilterAttribute.d__2.MoveNext()<br>--- <br>End of stack trace from previous location where exception was thrown ---<br>&nbsp;&nbsp; at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task <br>task)\r\n&nbsp;&nbsp; at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)<br>&nbsp;&nbsp; at System.Web.Http.Controllers.ExceptionFilterResult.d__0.MoveNext()"}

Adrian_Paech

PS we are running 'v7.4.2016.11' of the portal.

Adrian_Paech

Figured out a workaround for this.

It seems to be a problem with how the API is digesting some of the incoming JSON data.

For the attached example, the issue specifically lies within "HasRelatedWorkItems" objects.

Im not exactly sure which data was causing the issue within the related CI, however, I can workaround the issue by removing all properties for "HasRelatedWorkItem" and "RelatesToConfigItem" objects, except for BaseId, DisplayName and ClassTypeId.

This still applies changes as required, but strips CI's or unnecessary data.

Cireson Dev staff, have you guys seen similar issues in the past with interfacing the API via the portal?

Regards,

Adrian

Tom_Hendricks

Obviously not part of Cireson,so I am hoping they still jump in, but I did want to point out that the BaseId, DisplayName, and ClassTypeId are all that are needed to add an object to the model that you provide to the Commit call.  (I am not even sure that DisplayName is needed) So your workaround is actually a very solid way of handling this.

Adrian_Paech

Yea agreed tom. It certainly does the job nicely.. 

i guess, for those who are also trying to use the API, it might be a tricky thing for people to remember to do. It would be good if this issue was somehow handled and avoided within the API.