O365 Mail Reader Cannot Select Mailbox

So, I am not 100% sure if it is or isn't but my testing seems to indicate it is part of the issue. As removing one particular regex filter helped. But please keep in mind this appeared initially  to be random

An example would have been the following sender filter where I was wondering if length was the issue. I have obfuscated the domains, but the overall length is the same.
 
I reworked this to be smaller and changed it shape a little and I am now getting more consistent results and that "unable to select mailbox" error is not appearing

(?i)((^[a-zA-Z0-9\.\-]+@aaaaaaaaaaaaaaaaaa\.com$|^[a-zA-Z0-9\.\-]+@ccc-au\.com$|^[a-zA-Z0-9\.\-]+@bbbbb\.com$|^[a-zA-Z0-9\.\-]+@ccc-global\.com$))

The new version is below.

(?i)(^[a-zA-Z0-9\.\-]+@aaaaaaaaaaaaaaaaaa\.com$)|(^[a-zA-Z0-9\.\-]+@ccc-.*\.com$)|(^[a-zA-Z0-9\.\-]+@bbbbb\.com$)

Basically, it is filter on the email address domains. Any one from those domains with a general email address pattern. The "ccc" one is two of our own domains that had the first 3 characters. 

The regex was tested  at  regex101: build, test, and debug regex  and they have been in place for some time. The only recent change was that I added ccc-global element which is why I was wondering about length.

The other possibility is the () and the | or conditions

 

Hi Mike

This happened again today, and I know that you are in the dark as well. But I did everything to try and troubleshoot this.

* Removed all Filters
* Removed all RegEx's anywhere in the Package Action to Retrieve O365 Messages
* Told it to do Nothing with the message when finished
* Chose a mailbox connector with no variables in the name 

Continually failed. 

In the end I deleted the existing action object and created it again. but that has been done already a couple of times.

It ended up running. But the additional oddity is that if we run the same package via the Designer directly. It generally works. But when it runs a scheduled - fails. The other oddity but somewhat similar is that I built a special monitor package that executes other packages based on the existence of a trigger file. If we use this then the problematic package runs without error.

The common failure point seems to be the scheduler evoking the package. I know it doesn't make sense. But I am wondering if there is some type of variable leakage especially if there is any type of multiprocessing/multithreading happening.

Very much a problem for us. Because no mail messages is not an error as it is probable. But in this case the action ends as if it is an error which is also the case if there are no mail messages mathcing the filter. BUT we then have to test if messages found is zero which it also is and so the package ends as if it is all ok. Hence, we don't get any error alerts.


 
 
 




 

Hi Bruce

Can you post screenshots of the Recieve Email Oddice 365 object so we can see the options selected, please?



 

Hi. All of our packages follow a similar style when dealing with the mailbox. Today we had another different package experience the same failure. I'm convinced now it isn't the RegEx filters as I had tested by completely removing them. It is definitely triggered when the package is run by the scheduler but not when run through the desktop.

Requested screenshots attached.

I think the key to the issue is in the error message. It says it can't select mailbox ","    Note the comma. We don't have any variable that has a comma. Plus, the tests also failed when a specific folder was chosen without any variable in the name.

I have also included a screenshot of the log of the package successfully opening the mailbox. This is the exact same package running through the desktop UI. that repeatedly failed when evoked manually through the scheduler.

Whilst we would typically use a variable for the "_PROD" element. In these tests. I hardcoded the full folder path and no variable was in use

 
 
 

 
 
 



 

The comma is there because the actual error message should be

MailboxName comma ErrorMessage

Are you using a 32-bit version of our software or a 64-bit?

 

Hi. The server is running x64 which is where the scheduler runs. That's also where all the latest tests have occurred. both by the scheduler and the designer.