10.2.300.13 Task Agent Not Backwards Compatible

Epicor ERP 10
1

I have the most up-to-date Task Agent Service and I noticed the reports are not printing. Looks like the Task Agent is just continuously crashing.

The Bindings for the Instance and Agent are both UsernameWindowsChannel - I even reinstalled the Agent by uninstalling it, re-configuring it. I rebooted the Server.

Has anyone seen an error like this before:

AppServer Task Agent Event Log:

E10_Test: Agent SystemTaskAgent completed with the following error:
Error Detail:
The message with Action 'Ice:BO:SysAgent/SysAgentSvcContract/GetByIdForTaskAgentUse' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver.  Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).
Stack Trace:

Server stack trace: 
   at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter)
   at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Ice.Contracts.SysAgentSvcContract.GetByIdForTaskAgentUse(String agentID, Boolean firstPass)
   at Ice.Proxy.BO.SysAgentImpl.GetByIdForTaskAgentUse(String agentID, Boolean firstPass) in C:\_Releases\ICE\ICE3.2.300.13\Source\Shared\Contracts\BO\SysAgent\SysAgentImpl.cs:line 168
   at Ice.TaskAgentCore.TaskAgent.<>c__DisplayClass28_1.<RunAgentWorker>b__9(SysAgentImpl impl)
   at Ice.TaskAgentCore.ImplCaller.ImplCaller`1.Call[TResult](Func`2 doWork, ExceptionBehavior communicationExceptionBehavior, ExceptionBehavior timeoutExceptionBehavior)
   at Ice.TaskAgentCore.TaskAgent.RunAgentWorker(String serviceSettingId, String agentId, String appServerUrl, String userId, String password, String endpointBinding, String dnsIdentity, Int32 operationTimeout, Int32 maxConcurrentTasks, Int32 operationRetryCount, Boolean validateWcfCert, String directoryId, String nativeAppId, String webAppId, Object state, CancellationToken globalToken, CancellationToken agentToken, Boolean performStartupTasks)
2

The only thing I can think of is that 10.2.300.13 Agent has BO’s mismatched and is not backwards compatible with .12, .11, .10

3

I downgraded the Task Agent to 10.2.300.10 version and stuff works again with .11, .12…

So if anyone installs the Task Agent 10.2.300.13 - it did not work on any < .13 versions. Since I have multiple Instances and multiple versions for testing - I am just using .10 for time being.

Looks like they had some other issues recently, probably some minor Architecture changes in-progress. Thx @markdamen your post gave me an idea what to try :slight_smile:

1 Like
4

Can I ask why you do the minor updates? Unless there is a specific bug fix that you need it seems like a lot more risks than benefits.

5

When it comes to the Agent? Just because I’ve been bitten by it before stuff didn’t work sometimes or intermittently it worked, then the next time it didnt… and they improve the agent, fix bugs but not necessarily document them in the Excel. Actually the Upgrade guide doesn’t even say to update the Agent, but sometimes when you compare let’s say .2 and .3 you find alot of code change, tweaks etc…

When it comes to Epicor Versions: Alot of Bugs Fixed usually some major ones like “MRP Not Doing XYZ”.

Same with the Admin Console, I update it

6

Couldn’t one also argue, “Unless you know the software is perfect, seems like a lot more risk than benefit for running un-patched software - especially for Security bugs”?

Yes, there are risks with patching but not patching isn’t risk-free either.

Mark W.

7

@hkeric.wci We have too, which is why we never do the minor updates unless there is a specific bug fix for us.

@Mark_Wonsil For sure, software will never be perfect. But pushing out software just to hit a cadence and updating just because there is a new version both seem like a less than optimal way to build and deliver high quality software. I would be curious to see the amount of time from when Epicor is able to replicate a bug and when they release a fix for it.

1 Like
8

Completely agree with you here. If one is pushing releases just to meet a cadence then one is wasting time and reducing quality. I’m not so sure that’s what Epicor does today.

After talking to the devs (and the dev bosses) at Insights this week, I’ve realized that this is not your Father’s Epicor. They are doing what developers today should be doing. They’re taking any code they find that doesn’t have unit tests (legacy code), writing tests, refactor, repeat. I believe that is why the quality of the updates are very good in 10.2.

In that vein, I believe that once a bug is identified, a unit test (or integration test) is written first and then the code is written so that the test passes and no other existing tests fail (regression). Will they catch everything? Of course not but I truly believe it is better than what we have experienced in the past.

9

“Devil you know, vs the devil you don’t”

10

This reminds me of the Broken Window Fallacy which says as humans we are moved more by what we see vs what we don’t.

Mark W.