Fetch mail failing fails

Hey,

We have a flow that reads emails with the "Fetch email" action that suddenly started to fail with a error message we can't seem to do much about it.

Error: No account or login hint was passed to the AcquireTokenSilent call. 
Source: action "Fetch email", module "Main", table "Fetch email + attachments from ....."

When researching the error i only find .NET forums with help and no specific authorization fault.

Testing the connector trough the connector manager seems to work and send email,


but when we use a fetch or send email action we get the error as mentioned

We recencelty re authorize the connection, after the new authorization it started to fail with the above error. We also recencelty upgrade to an new version from em 5.6.1 to 5.7.3.3.

We use a Mircosoft Exchange Online type connector with Oauth authentication and no custom Oauth app. It seems to fail on the server as EM desktop.

Do you know why this error could happen or some steps to receive more information about the error?

Debug log:

Source: action "Fetch email", module "Main", table "Fetch email + attachments from service_afas_netsuite@moore.be"

[0] Exception message: No account or login hint was passed to the AcquireTokenSilent call. 
[0] Exception type: MsalUiRequiredException
[0] Exception source: Microsoft.Identity.Client
[0] Exception stack trace:    bij Microsoft.Identity.Client.Internal.Requests.Silent.SilentRequest.<ExecuteAsync>d__5.MoveNext()
--- Einde van stacktracering vanaf vorige locatie waar uitzondering is opgetreden ---
   bij System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   bij System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bij Microsoft.Identity.Client.Internal.Requests.RequestBase.<>c__DisplayClass11_1.<<RunAsync>b__1>d.MoveNext()
--- Einde van stacktracering vanaf vorige locatie waar uitzondering is opgetreden ---
   bij System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   bij System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bij Microsoft.Identity.Client.Utils.StopwatchService.<MeasureCodeBlockAsync>d__4.MoveNext()
--- Einde van stacktracering vanaf vorige locatie waar uitzondering is opgetreden ---
   bij System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   bij System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bij Microsoft.Identity.Client.Internal.Requests.RequestBase.<RunAsync>d__11.MoveNext()
--- Einde van stacktracering vanaf vorige locatie waar uitzondering is opgetreden ---
   bij System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   bij System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bij Microsoft.Identity.Client.ApiConfig.Executors.ClientApplicationBaseExecutor.<ExecuteAsync>d__2.MoveNext()
--- Einde van stacktracering vanaf vorige locatie waar uitzondering is opgetreden ---
   bij System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   bij System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bij Morph.DataDrivers.Common.Azure.AzureAuthenticator`1..MoveNext()
--- Einde van stacktracering vanaf vorige locatie waar uitzondering is opgetreden ---
   bij System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   bij System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bij Morph.DataDrivers.Common.Azure.AzureAuthenticator`1..MoveNext()

Kind regards,
Daan

Hello Daan,

Thank you for the detailed report. We are looking into this issue.

Daan, we were able to replicate this error with an existing connector. It seems that newly created connectors are not affected by this error. Please create and authorize a new connector instead of the old one and check if the "Fetch email" action works with it.

Hi Andrew,

Yes indeed newly created connectors seem not affected. I recreated the connector and switched them in the project., now i don't get the error and it works.
Thnx for the quick response.

hi @andrew.rybka @dgudkov

I have a well-founded suspicion that the connector has a expiry period of 14 days (we need to extend that) as we are now again facing the 'AADSTS70043' error message:

I refreshed (or 'reset') the new connector, all seemed fine, sending the test mail works well.

Please note: we recreated the connector 2 weeks ago under version 5.7.3.3.

But restarting the flow generates another error:

Recreating the connector (again) should solve the issue but this doesn't seem to be a durable situation? Can I consider it a bug ?
It there something else I can try ?

Thanks in advance

Hi @laupie, to address the part of your question:

The issue with 'acquire token silent' was fixed only in 5.7.3.4 only, e.g. to fix it you need to update to 5.7.3.4 and recreate the connector

hi @olysak Okay, thanks for the info - and the bugfixing. We'll give it a try and if you don't hear back from us all is fine :slight_smile: