System agent schedule after Daylight Savings time on SaaS?

Has anyone noticed issues with jobs scheduled via the system agent failing or crashing this week? I have MRP scheduled to run at 11PM EST nightly and it’s crashed each night since Sunday’s time change. I’ve seen other threads about an update, but since we’re on cloud I don’t control that.

Do your schedules have the Time Zone set within System Agent Maintenance? As of Kinetic 2024.1 (for Kinetic Cloud customers–do not recall the specific 2023.2 point update where this was addressed for on-prem customers), any schedules with a time zone explicitly set within System Agent Maintenance will continue to execute at the same local time set on the schedule when DST changes.

5 Likes

Yes I had it set to Eastern Time. However while looking at the list I see there is and Indiana East, which I’m in. Perhaps it should be set to that one? Scheduled start time is 11PM.

image

What is “crashed”?

It gets stuck on a random part number and won’t complete, just runs on the stuck part number for hours. The Log shows this error:
3:30:08 System.Data.Entity.Core.EntityCommandExecutionException: An error occurred while executing the command definition. See the inner exception for details.
—> System.Data.SqlClient.SqlException (0x80131904): A transport-level error has occurred when receiving results from the server. (provider: Session Provider, error: 19 - Physical connection is not usable)
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action1 wrapCloseInAction) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose) at System.Data.SqlClient.TdsParserStateObject.ThrowExceptionAndWarning(Boolean callerHasConnectionLock, Boolean asyncClose) at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error) at System.Data.SqlClient.TdsParserStateObject.ReadSniSyncOverAsync() at System.Data.SqlClient.TdsParserStateObject.TryReadNetworkPacket() at System.Data.SqlClient.TdsParserStateObject.TryPrepareBuffer() at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady) at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData() at System.Data.SqlClient.SqlDataReader.get_MetaData() at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, SqlDataReader ds) at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior) at System.Data.Entity.Infrastructure.Interception.InternalDispatcher1.Dispatch[TTarget,TInterceptionContext,TResult](TTarget target, Func3 operation, TInterceptionContext interceptionContext, Action3 executing, Action`3 executed)
at System.Data.Entity.Infrastructure.Interception.DbCommandDispatcher.Reader(DbCommand command, DbCommandInterceptionContext interceptionContext)
at System.Data.Entity.Core.EntityClient.Internal.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior)
ClientConnectionId:8b57873e-476e-4d0a-930b-e841904b984b
Error Number:-1,State:0,Class:20

I’m not sure why or how this relates to DST. Sounds unrelated…

1 Like

I think Error 19 is a problem with the SQL connection…not so much the scheduler. Timeout or connection-string issue? Any way to check the SQL server for errors around that time?

No, not with SaaS in cloud.

Yeah, I’m just resetting all of my schedules to run an hour earlier so it won’t be a possibility next year.

I wonder if it kicked off twice because of the time change, and since it was running twice, causes some sort of… corruption? For lack of a better term.

1 Like

For those that are on Kinetic 2023.2 and experienced issues with when schedules started after the DST change this past weekend:

The code change to resolve the issue with system agent schedules not correctly starting at the expected time when DST begins or ends was introduced in Kinetic 2023.2.10+. The fix was to the TaskAgent Service code and would require reinstalling the TaskAgent Service from the …\ERP11\ERP11.2.400.0\Updates\ERP11.2.400.latestpointupdate\SupplementalInstalls\Task Agent\Task Agent Service Installer.exe after updating the Kinetic appserver process to 2023.2.10+.

1 Like