SAP IRPA - Job 0f509ccd-3f95-4326-a323-47500b0a5811 has expired

[former_member699645]

After a execution of one job, this log appears: it shows as the job has expired.
but there is no error in the Agent, it's change from running status to Idle.

I changed the default timeout from 10 minutes to more on the properties of workflow, but not works.

is there another way to solve this problem?

[mael_leboite]

Hi,

The 2009.03 update of the factory has been released.

It includes a fix for the unexpected job expirations.

Best Regards,

Maël

[mael_leboite]

Hi,

You may face a probable issue with the job expiration.

The dev team is actively working on a fix as they found the cause of the issue.

There is a workaround:

• The following workaround should be working for those that are facing issue with the factory (https://launchpad.support.sap.com/#/notes/2956669)
• The workaround is pretty bothersome and prone to errors (multiple manual modifications + potential flushed factory variables). Variable may be flushed from your project as well.
• It is then strongly advised to create an archive of your project before applying it.

BUT, Job expiration can also be a normal behavior:

• Unsynchronized timeout values
• Wrong imported version
• Agent running long synchronous code block

To be sure that the you are facing this issue, some verification needs to be done (Providing also a bit of background around timeouts.)

1. Timeout check
2. Version check
3. Job detail check

1. Timeout check:

Timeout in the code and on the Workflow are 2 separate things

• Workflow timeout ==> Factory timeout
• Scenario timeout ==> Agent timeout

When creating the workflow for the first time and as long as you keep using the merging tool the timeout may keep being synchronized.

• Once you start modifying the code deeper and particularly the timeout in the code, then the timeout of the workflow (in the ui) and the timeout of the scenario (the code) may be unsynchronized.
• Modification of the code NEVER modify the workflow ==> possible unsync
• If there is no merging tool, then update of the workflow timeout may not be taken into account.
• If Agent timeout > Factory timeout and Effective time of the job is > Workflow timeout then the Factory decides that the Job expired and that the Agent is out of reach and won’t try to communicate with it anymore ==> Disconnection of the Agent from the Factory Point of view

Possibly the Job will keep running on the Agent side, particularly if

• some synchronized code keeps running preventing to get news from the Factory

• the Agent maybe get stuck and not respond anymore preventing to get news from the Factory (the job expiration / Agent disconnection is a failsafe for this case).

2. Version check :

It is essential to check the versioning of the different exported packages, as well as of your job.

Moreover, there is 2 versioning systems:

• Factory Package version
• Studio Package version

You will have to compare those 2 versions:

• In the below sample, the failed job is using Factory package version 2.0.0

• 2 exports have been generated with the Studio

• the desktop studio package export 1.0 may have different workflow timeout from the 2.0

• The studio package version 1.0 is used by the Factory Package version 2.0.0

It is then very important to do the link between the failed job, the Factory package version, the Studio package version and its timeout.

In the 2010 Factory version we expect to see the Workflow timeout directly in the Factory

3. Job detail check:

If the Job is running the proper studio package with an expected longer timeout than experienced

Then a last check needs to be done by going on the detail of the Expired Job:

By checking the traces, we should be able to see if there is any inconsistency:

{"jobRunResponse":
   {"runUid":"……………………………………………………………………….", 
      "name":"scenarioAddJob", 
      "runInfo":{..., 
         "expirationDate":"2020-09-10T15:13:03.421Z" 
      }, 
      "studioMode" : false, 
      "timeout" : 1500
   },
   ..., 
   "packageVersion":{ 
      "major":2, 
      "minor":0, 
      "patch":0 
   },
   ..., 
   "runStatusResponse":[..., 
   { 
      "updated":"2020-09-10T15:02:33.421Z", 
      "runStatus":"running", 
      "detail":"" 
   },
   ...], 
...
}

In the sample above,

• "studioMode" : false,
• Factory package version is 2.0.0
• expirationDate - Running Run status = 15:13:03 - 15:02:33 = 10 minutes + 30 seconds
• timeout = 1500 seconds = 25 minutes

10 minutes + 30 seconds != 25 minutes ==> There is inconsistency.

The 10 min is the default value in a new project in the studio, but also a default value in the Factory (if a project is launched from the studio for instance)

Although having this expired job, it could be normal if launch through the debugger and that can be seen if "studioMode": true,

Be aware again that a Job expiration is not necessarily a Factory issue and may come from unsynchronized timeout Workflow vs Scenario (Code timeout > Workflow timeout), stuck Agent on synchronous loop or potential Bot Design flaw.

Regards,

[former_member690337]

Same here, pls fix

[former_member699645]

Hello Raaj.

I Set the timeOut in the properties panel (seconds):

Checked the scenario, to change to miliseconds:

But i have the same problem on the log:

Thank you!

[former_member245352]

Hi Matheus

After changing the timeout in the workflow. Did you check that the changes were reflected after the build in this line of code - sc.setScenarioTimeout(60000000);

Workflow Timeout takes value in Seconds

The above Code takes Value in Milliseconds.

Both must be same.

Regards,

Raaj