Since the linux migration, functions that are the second or third task in a process set aren’t running. I have one that goes to pending every night and never executes (so far this has happened every day since Saturday, when the system was migrated to linux), and another that never appears in the task agent at all. Deleting the function from the process set and resubmitting it doesn’t fix the problem. Other tasks in the process set execute successfully. There are no errors. Running the function manually on demand works. Support has not responded. This is critical as we rely on scheduled functions to send out customer documents, correct data in the system, etc. I can’t keep running things manually every day. Any ideas why the linux migration specifically would have broken this? The system was not upgraded so this is not a 2026 issue. Public cloud 2025.2.16. Have already restarted both the site and the instance in the CMP.
I extracted all server log files and sys agent records to AI to help figure out what is going on, since Epicor support is MIA as usual. Here is the answer.
Scheduled Epicor Functions inside Process Sets stopped running after Linux migration (Kinetic SaaS)
Symptoms
After our Epicor Kinetic SaaS environment was migrated to Linux app servers over the
weekend, Epicor Functions scheduled **as members of Process Sets** stopped running:
- A function that runs as the last task in two process sets (nightly MRP set and a
midday PO-suggestions set) never runs anymore — and leaves **no trace at all** in
System Monitor. The native tasks in those sets (Process MRP, Generate PO
Suggestions) still run fine every night. - In a nightly set with two function members (ship confirm, then email pack slips),
the second function shows **PENDING in System Monitor forever** and never executes.
On some nights the set produced no task records at all. - Functions scheduled **standalone** (directly on a schedule, not in a process set)
all still run fine post-migration.
Root cause
When the task agent fires a process set, it copies each ProcessTask member into a
SysTask row and runs them in sequence. Members created by scheduling an Epicor
Function get the auto-generated description:
Epicor Function (<LibraryID>.<FunctionID>)
That wrapper adds 18 characters, so any `Library.Function` combination longer than
**32 characters** produces a description longer than **50 characters** — the max
length of `SysTask.TaskDescription`.
- The **old Windows app servers silently truncated** the description to 50 on insert.
(Proof: all pre-migration SysTask history rows for these functions are stored at
exactly 50 characters, cut off mid-name.) - The **new Linux build (ICE 5.1.100) enforces the max length and throws** instead.
In the server logs, at the exact second each process set fires, the task agent’s
member-creation call fails:
Ice.Services.BO.SysTaskSvc/Update
Ice.Common.BusinessObjectException: The maximum number of characters allowed
for Description is 50
The sequence in the log is unmistakable: `ProcessSetSvc/GetRows` →
`ProcessTaskSvc/GetRows` → `SysTaskSvc/GetNewSysTask` → `SysTaskSvc/Update` → the
exception. I confirmed the identical exception at the firing timestamp of all three
affected schedules, including a manual re-run of one set.
Why each symptom looks the way it does
- Members whose `Library.Function` exceeds 32 chars → the SysTask insert **throws**,
so the task is never created. Nothing to see in System Monitor — it just
silently doesn’t run. - A member whose name happens to fit (ours was 29 chars) → its SysTask row **is**
created, but the set’s sequential chain already broke on the failed member before
it, so nothing ever starts it. It sits PENDING forever. - Native process members (MRP, PO Suggestions, reports) have short descriptions →
unaffected, which makes the set look “half working.” - Standalone scheduled functions use a different description format (`eFX: …`)
that is already truncated to 50 chars at *schedule* time and stored in
`SysAgentTask.TaskDesc` — so that path still works on Linux.
Workarounds / fixes
- **Schedule the functions standalone again** (directly on schedules, staggered
times to preserve ordering). This path is proven working post-migration. - Or keep the process sets but get each member’s description ≤ 50 characters —
practically, keep `LibraryID.FunctionID` ≤ 32 characters, or fix
`ProcessTask.TaskDescription` on the member rows. Test in Pilot first. - **Report it to Epicor support as a regression**: on the Linux/Kubernetes build,
process-set instantiation of scheduled-function members hard-fails on the 50-char
Description validation instead of truncating like the Windows build did. - After fixing, clean up any stuck PENDING function tasks in System Monitor —
they never get picked up again.
How to confirm you’re hitting this
- `Library.Function` name longer than 32 characters, scheduled inside a process set.
- SysTask history: pre-migration rows for the function have descriptions cut off at
exactly 50 characters; post-migration rows are missing entirely (or PENDING). - Server log at the schedule’s fire time shows the `BusinessObjectException` above
under the task agent user, immediately after `ProcessSetSvc/GetRows`.
@timshuwy / @Epic_Santiago this feels like another issue that should be run up the flagpole and looked at sooner rather than later. People are going to have failing functions in process sets and not realize it.
We run over 50 characters often, but it truncates it in 2025. Yikes!
Same with MailLog we put lengthy emails and it truncates, I wonder if it starts failing… some of the MailLog columns are so tiny.
@aosemwengie1 did you report this information to support? what is the case numbe if so? This is important info, and should help expadite the triage. I will pass it to the backend as well, but info really helps.
CS0005561236 is my case number.
Did you confirm that if you rename your function a super short name it fixes the problem? That’s nuts! nice find
Well, so, no. Because now I am running into the other issue where when you publish a new library, Epicor’s load balancing doesn’t see the function and gives a 404.
Could you try it now that we have that code from Epicor in the uBAQ?
Yes confirmed the shortername fixed the problem.
That’s good. But Epicor still needs to fix. And fix the email one. Sounds like they are… 
Confirming it is up the flagpole.
Want to +1 that we’ve been running into related issues.
We threw our hands up in the air last night hoping it would be fixed in the morning, but no such luck.
Here’s a list of the problems we’ve been experiencing on our LIVE environment on Epicor version 2025.2.16 since ~6:00pm PST last night:
-
Hooking up a Kinetic Function call to a simple App Studio Event gives an “undefined” error almost always. Later after ~8:00pm PST, we noticed that the “undefined” errors became “Library/Function is not published” error around 50% of the time. The other 50% was still a blank undefined error.
- Note: Our Library + Function name was over 32 characters in some cases, but still was occuring in other Library + Function names that were only 24 characters.
-
Also noticing that newly published (and properly authorized) Function Libraries are not visible to Kinetic-Function widgets in App Studio.
-
Using Schedule Epicor Function (Immediate) seems to work sometimes, but is not working now. Here are the current errors I’m receiving (with a short and long Library+Function name) when running with Schedule Epicor Function:
Exception executing library ‘EE-Processes’ function ‘OrderTaxRegionCodeRecalc’:
System.InvalidOperationException: The function ‘EE-Processes.OrderTaxRegionCodeRecalc’ is disabled.
at Epicor.Functions.Runtime.EfxRuntimeExtensions.GetFunctionInfo(IFunctionsCatalog functionsCatalog, FunctionRefId refId, String forCompany) in C:_releases\ICE\ICE5.1.100.0\Source\Server\Customization\Epicor.Functions.Runtime\EfxRuntimeExtensions.cs:line 43
at Ice.Internal.Task.ScheduledFunction.ExecuteFunction.GetFunctionAdapter(String libraryId, String functionId) in C:_releases\ICE\ICE5.1.100.0\Source\Server\Internal\Task\ScheduledFunction\ExecuteFunction.cs:line 117
at Ice.Internal.Task.ScheduledFunction.ExecuteFunction.RunProcess(Int64 instanceTaskNum, String outputFileName) in C:_releases\ICE\ICE5.1.100.0\Source\Server\Internal\Task\ScheduledFunction\ExecuteFunction.cs:line 52Exception executing library ‘ee-testing’ function ‘RestoreAuthorID’:
System.InvalidOperationException: Can’t find function ‘RestoreAuthorID’ in ‘ee-testing’ library
at Epicor.Functions.Runtime.EfxRuntimeExtensions.GetFunctionInfo(IFunctionsCatalog functionsCatalog, FunctionRefId refId, String forCompany) in C:_releases\ICE\ICE5.1.100.0\Source\Server\Customization\Epicor.Functions.Runtime\EfxRuntimeExtensions.cs:line 35
at Ice.Internal.Task.ScheduledFunction.ExecuteFunction.GetFunctionAdapter(String libraryId, String functionId) in C:_releases\ICE\ICE5.1.100.0\Source\Server\Internal\Task\ScheduledFunction\ExecuteFunction.cs:line 117
at Ice.Internal.Task.ScheduledFunction.ExecuteFunction.RunProcess(Int64 instanceTaskNum, String outputFileName) in C:_releases\ICE\ICE5.1.100.0\Source\Server\Internal\Task\ScheduledFunction\ExecuteFunction.cs:line 52 -
A Final Note: We restarted the Site + Instance utilizing Epicor Cloud Tools, and it seemed to fix the issues for ~10 minutes, and then reverted to the current broken behavior again. I believe this might be due to the library getting unpromoted and repromoted after a change, but I can’t reconfirm easily at this time.
You don’t post much so I’m glad you took the time to add your voice. It shows how much this is impacting companies- even those we don’t hear from often. Sorry you’re dealing with this.
Thanks for the callout!
I do consulting for lots of smaller companies, and this is definitely affecting us.
I just realized there is a much larger thread that is more directly related to my post so I’ll repost our findings there. Sorry to muck up the waters, since we aren’t directly using process sets!
So far the only response from support is to recycle the app pool after making changes, but of course that a) requires down time and b) doesn’t even work since this issue has nothing to do with changing functions, but instead has to do with the 50 character limit.