Loop54 add-on PushProcessor exception

We’re having an issue where free gift campaigns sometimes are being “temporary suspended” and the free gift isn’t added to the customer’s cart even though the conditions are met.

The following is logged by the Litium.Foundation.Modules.ECommerce.Plugins.Campaigns.ICampaignProcessor:

Message	Campaign 'foo' temporary suspended, reason: Exception has been thrown by the target of an invocation.

The reason seems to be an error in the Loop54 push processor via the TargetGroupSessionEngineImpl which is invoked when the free gift is added to the cart by the campaign action.

In Litium.AddOns.Loop54.PushProcessor.Process(TargetGroupContext context, ITargetGroupEvent targetGroupEvent)) there is an attempt to fetch the current channel (see code below). However this fails sometimes which causes a NullReferenceException.

public void Process(TargetGroupContext context, ITargetGroupEvent targetGroupEvent)
	var currentChannel = ((RouteRequestLookupInfoAccessor)context
		.GetField("_routeRequestLookupInfoAccessor", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance)

Full stack trace:

   at System.RuntimeMethodHandle.InvokeMethod (mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal (mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.Reflection.RuntimeMethodInfo.Invoke (mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at Litium.Foundation.Modules.Relations.Plugins.TargetGroups.TargetGroupEngineWrapper.Process (Litium.Studio, Version=, Culture=neutral, PublicKeyToken=093d4a638630e7c5)
   at Litium.Foundation.Modules.ECommerce.Plugins.Checkout.CheckoutFlow.AddOrderRow (Litium.Studio, Version=, Culture=neutral, PublicKeyToken=093d4a638630e7c5)
   at Litium.Foundation.Modules.ECommerce.Plugins.Campaigns.Actions.FreeGiftAction.Process (Litium.Studio, Version=, Culture=neutral, PublicKeyToken=093d4a638630e7c5)
   at Litium.Foundation.Modules.ECommerce.Plugins.Campaigns.CampaignProcessor.Process (Litium.Studio, Version=, Culture=neutral, PublicKeyToken=093d4a638630e7c5)
   at Litium.Foundation.Modules.ECommerce.Plugins.Campaigns.CampaignProcessor.Process (Litium.Studio, Version=, Culture=neutral, PublicKeyToken=093d4a638630e7c5)
Inner exception System.NullReferenceException handled at System.RuntimeMethodHandle.InvokeMethod:
   at Litium.AddOns.Loop54.PushProcessor.Process (Litium.AddOns.Loop54, Version=, Culture=neutral, PublicKeyToken=nullLitium.AddOns.Loop54, Version=, Culture=neutral, PublicKeyToken=null: D:\a\1\s\Litium.AddOns.Loop54\PushProcessor.csLitium.AddOns.Loop54, Version=, Culture=neutral, PublicKeyToken=null: 48)
   at Litium.Web.Customers.TargetGroups.TargetGroupSessionEngineImpl.Process (Litium.Web.Application, Version=, Culture=neutral, PublicKeyToken=093d4a638630e7c5)

We’ve added a null check for now in the Litium.AddOns.Loop54.PushProcessor.Process() but this means that the event won’t be registered.

Any ideas on how to fix this?

Litium version: 7.4.3

So it fails because:

.GetField("_routeRequestLookupInfoAccessor", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance)

is null? or is context null?

We haven’t been able to debug and reproduce it but I’d guess context is not null.

If the context is null then the thread does not belong to any specific channel and it will be hard to figure out the correct channel.

Context is probably not null.

And yes, if this runs in a separate thread it won’t have knowledge about any channel. I’d like some thoughts from you whether the implementation of Loop54.PushProcessor.Process is correct or if you think it might need some fixes. We have not adjusted the add-on code in our project.

This section of the AddOn should be fine (check the BindingFlags if some flag is missing) but all scenarios from different customers custom implementations might vary off course and that’s why we deliver this addOn as source code. You can debug and see where the issue is and notify us so we can also change the implementation if you would have a fix for it.
But I would recommend you to wait for a new version that we gonna release (or pre-release) maybe next week since lot of changes have been done to this addOn specially with the faceting logic and call caching parts.

This particular error does not seem to be dependant on our custom implementation.
Is there a pre-release we can try to see if the issue has been resolved?

We will try to release a new version this week but this section of code is not altered so no change will occur on this logic. Did you debug and found the exact issue?

No, we have not reproduced this locally.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.