In one Sequence, there is an Wait Queue Item and Resume activity. Works fine.
In another Sequence, there is an Office 365 Scope, with a Get Email By ID and then a Move Email. All of that is inside a Try. We expect that sometimes the email will already have been moved and just want it skipped if Move Email can’t find it, so we just move on.
The automation runs fine…until Move Email faults because the email is already in the folder we are trying to move it to. The Try then generates the exception variable as UiPath.MicrosoftOffice365.Office365Exception to hand off to the Catch.
The instant this happens, the entire Job faults with:
Type ‘UiPath.MicrosoftOffice365.Office365Exception’ cannot be serialized.
This makes no sense. That exception variable should not be exposed to any other scope besides the Try, and the Wait activity is not inside this Try.
Is this a bug? There is no reason the exception inside the Try should have any relevance to a Wait activity in another scope that isn’t even being executed at the time of the exception.
as a walkaround, we can catch the exception with exception function and then check if exception is move email related or not, else rethrow the exception
This is a bug Paul, specifically with the O365 activities and it only affects Background processes if I recall correctly.
Give me a few and I’ll see if I can find a reference where I report it to a product manager.
Ok, it seems it was something I perhaps talked to them about on a ticket and I don’t have access to that right now. But basically this occurs because of a bug in the O365 packages and has the bizarre nuance that it only affects background processes, not foreground ones (if my memory serves me correctly).
This project is not specifically set to run in the background, but it doesn’t have any UI automation. It just grabs a queue item, creates a queue item in another queue and waits, then moves the email. Any chance the bug doesn’t exist in a different version of O365 or Persistence?
We’re using O365 2.7.24 and Persistence 1.4.8. Also System 24.10.7.
One thing that perplexes me is why “continue on error” has disappeared from so many activities, but that’s a topic for another day. It would presumably solve this problem for us.
Thats my faulty memory then, its related to it being a persistence activity then.
I believe you can confirm this by making a fresh project where you do a Send Mail activity but enter a clearly invalid email in the ‘To’ field.
This will throw the 365 error.
If you test it as a normal project, then as a background project, then as one that supports persistence you should be able to confirm its the same behaviour I reported.