Occasionl Null reference exception in for each block

bugs
1

An occasional null reference exception has been reported in the workflow for each block. We should add logging to better diagnose the problem.

2
3

It looks like the source of the null point exception was that the _call was set tool late. Basically, the handler was first registered

  this.Engine.Host.WorkflowFinished += Host_WorkflowFinished;

And the call was set shortly after that.

_call = this.Engine.GetSubEngine(block, Engine.TransactionBehavior);

So that’s why it appears to be null in the logs, although it’s never set to null anywhere in the. So what was likely happening is that some other workflow had finished and as a consequence the handler was called and before it could determine whether or not this is the right workflow and it should run, it crashed because the call was null.

if (e.Engine.WorkflowUniqueId.Equals(_call.WorkflowUniqueId))

So in the end the fix is quite simple, just move the call assignment before the handler registration. If this indeed proves to be the cause, then there will be another pull request that removes the debugging code and simplifies things.

1 Like
4

I don’t understand why all the other logging code is there – why do we log SQL particularly inside for-each block? Is SQL in any way interesting for the logging here?

Also why was UnsubscribeEvents() call removed everywhere? It is quite important otherwise this instance will not get garbage collected and will cause memory leaks.

5

The login code is there because we are trying to figure out what’s going on in this particular edge case. It will be all removed once we confirm that this is the actual solution to the problem.

I actually added the unsubscribe events in the previous iteration when trying to solve this problem and they caused even more problems. So now I’m scaling them back and only keeping them where they were originally.