Error: Http request failed: the content was not a valid JSON. Error while parsing JSON: 'Unexpected character encountered while parsing value: R. Path '', line 0, position 0.'

[E_S]

I am trying to write a flow and I get this error:

Http request failed: the content was not a valid JSON. Error while parsing JSON: 'Unexpected character encountered while parsing value: R. Path '', line 0, position 0.'

The flow it's really simple, variables and an execute query.

I am trying to get texts from power app and use them to modify a string variable in power automate. Then I use the modified string variable as a query. 

I start with a trigger from power apps and I specify what I want to save as a variable and use in power automate:

Then I have a variable to save my query as a string and I use the previous variable to modify it (I find it in the required fields). 

Here it seems that everything works, but I do not understand what  is "Impostavariabile_valore". 

The error appears in the last step, when I try to execute the query

Can you give me some advice? 

[AnnRGM]

I submitted a ticket yesterday. This is so frustrating because it's happening on a multi-approval flow that creates an audit trail for SOX compliance. Resubmitting a flow after emails have already been sent and approvals have been made is not just time-consuming, it feels very unprofessional. I guess I will also have to improve the error handling in the flow (but why should I need error handling for sending an email when I've already validated recipient, etc.?)

Has this occurred for anyone since Nov 7?

One thing that has helped tremendously is the ability to show custom columns in the Power Automate history of flow runs. I can now tell at a glance which flow goes to which SharePoint list item.

[Anonymous]

@AnnRGM - yes, seeing the columns is an incredible improvement!!  How are you validating email recipient?  
Thank you!  

[nerfherder]

Thank you @AnnRGM ! That's probably what caused the failures to stop. Haven't had any since ~ 10 PST on 11/7. We use email primarily to communicate rather than approve, thankfully, so most of the impact of this bug was superficial.

[AnnRGM]

Our process is completely internal, so the users are all in our Active Directory. BUT, I found out that just because a user is in AD doesn't mean they are a valid user according to Approvals or Outlook, so I always validate via Office 365.

[nerfherder]

Had another failures today at 3:55 PST. We use confirmation emails internally and when reps don't get em they're trained to resubmit. the reps resubmit went thru so I didnt have to. MSFT please fix ❤️

[binki-dcx]

Thanks for filing the ticket, @AnnRGM . If Microsoft has any explanation for the issue, that’d be interesting.

I don’t think that email recipient verification is related to this issue at all. I am pretty sure that the action for sending an email does not in any way care about the success of the email’s delivery. All it does is queue a message for sending in Outlook. If it waited for delivery confirmation of some sort, you’d see very long action runtimes. That’s simply not how email normally works.

@David_PezzoliI am using “Reply_to_email_(V3)'”. That is the latest version of the action, not one of the deprecated ones. I got the error once. It is in a flow which runs periodically, so there was no surge in volume and my flows do not get close to any of the resource limits, so it being a limit issue specific to my account is out of the question. This appears to be a global service outage of some sort, though it was random and transient enough that it likely only affected a small percentage of calls while it was occurring, making it harder to be noticed.

@David_PezzoliFor this error, checking common errors does not make sense. The error itself is “Http request failed: the content was not a valid JSON. Error while parsing JSON: 'Unexpected character encountered while parsing value: R. Path '', line 0, position 0.'”. For me, the error occurred on the action after it was only running for 1 second. So it is not like a timeout in the request caused the request to be truncated. It is more like the service had an internal error and returned an HTML error response when the connector was expecting JSON—or something of that nature. The letter “R” doesn’t make sense if the issue is actually the server returning an HTML error instead of a JSON one. Maybe the server returned a textual error saying something like “Request failed” and the connector doesn’t even check the Content-Type of the response or HTTP status code before trying to parse the result as JSON. Maybe the connector sent invalid data due to, as I suggested above, writing the headers out of order (the fact that the bad character is a capital letter R suggests either that it is the beginning of the sentence or an HTTP header), or some debug logging making it into the request body.

Maybe, just maybe, the “REST API is not yet supported for this mailbox” is the error we are seeing. If the response were a text/plain response with just that message but the connector doesn’t check the response type and just blindly tries to parse it as JSON, one would get the error shown above. However, the explanation for this error clearly describes this as a non-transient error. If the service temporarily incorrectly returned this error (but the connector obscured the error), then there must have been some other service outage or incorrect error handling in the connector or API itself which resulted in the API incorrectly assuming that the user’s account was not set up for RESET access even though it was actually some other transient issue. E.g., maybe Microsoft was deploying an update and, while the REST API was not working, the connector assumed that the seen error indicated that the REST API was disabled when it was really just temporarily down. But, again, how are we supposed to know this was the error from the error message we saw?

That is very unlike the nature of the common errors we are supposed to be handling. A proper error should still have a well-formed response or a clear “connection reset” error message if there was actually a lower-layer communication error. If such an error occurred but the connector’s own error handling was failing and, in trying to display the error, encountered this error related to JSON parsing, then we cannot know the actual error because the JSON parsing error is obscuring the actual error. If, as in the OP’s post, there is malformed OData, then the server should respond with a clear message saying so—not give some error which looks like an internal error that is not properly handled and labeled as such. I.e., this is not something that we can solve or fix from our end. Microsoft needs to fix error handling somewhere before we can actually see what is wrong. But this is hard if it is a transient error which is no longer happening.

If I need to have retry loops in my flows for this type of thing, that would be just silly. I would expect the action to automatically retry calls that are safe to retry. If the call is expected to fail transiently, the API documentation should clearly explain that for the action and give an explanation of how to detect a transient error and how to retry it. I don’t see this in the Outlook connector documentation. But… if the action is actually safe to retry, that means I have to add a retry loop to many of my flows, complicating them. Again, this complication should be hidden from me. And, this very error is not well-formed enough to determine that it even is a transient error or that retrying is safe.

[AnnRGM]

@nerfherder Thanks for the update...very disappointing to hear that you experienced another failure yesterday.

@binki-dcx I agree that the email recipient is not causing the problem. My point is that I shouldn't have to check for an error on a "Send email" step...I've already handled possible error cases before I send the email. Even if I do check for an error, I can't solve the problem in the flow. Not in this particular case, where we have multiple approvals required. Resubmitting the flow generates new approval ids and redundant emails.

Just to vent, this error causes me headaches even if we get through the approval steps. If an email near the end of the process fails, SharePoint can't update statuses and the whole audit trail is broken.

I'll update this thread when I hear back from Microsoft.

[nerfherder]

@AnnRGM best practice would be to avoid email for any important organizational function other than notifications, as a fall back. That's essentially how we're using it, but may rely heavier on it in future. Not sure if it would work for your org, but there are plenty of vendors with Power Automate connectors for sending text messages.

[Dharam2]

I am facing same error with below connector:

Send an email (V2)

Office 365 Outlook

Please help me out. This issue is occurring frequently.

[nerfherder]

@Dharam2 seems like this is something that Microsoft needs to fix. Quick question though for you and @AnnRGM , are you all using the same connection across many flows? Or have you used multiple different Outlook connections throughout your flows?

[Dharam2]

@nerfherder 

Are you all using the same connection across many flows?

Yes

Or have you used multiple different Outlook connections throughout your flows?

Yes

[binki-dcx]

@Dharam2Please see if you can open a support ticket with Microsoft. I do not expect them to be monitoring this thread, but we need their input. If the issue is happening frequently for you (I only saw it once on November 7 myself), that might help them in identifying the issue. And, more importantly, it raises their awareness. Thanks!

[Dharam2]

@binki-dcx Thank you for your reply. I will try to open a ticket with Microsoft.

[AnnRGM]

Are you all using the same connection across many flows?

Our organization has 40,000 employees, so I have no way of knowing if other flows are failing. I only have one flow that is failing but my other flows run infrequently.

Or have you used multiple different Outlook connections throughout your flows?

This flow uses the Send an email (V2) connector six different times throughout the approval process. Sometimes the email is a notification, sometimes the email contains approval links. The email always contains an HTML table of data.

I shared this thread with the Microsoft engineer assigned to my ticket. I've just sent an email requesting an update and requesting they view this thread again.

[AnnRGM]

Are you all using the same connection across many flows?

Our organization has 40,000 employees, so I have no way of knowing if other flows are failing. I only have one flow that is failing but my other flows run infrequently.

Or have you used multiple different Outlook connections throughout your flows?

This flow uses the Send an email (V2) connector six different times throughout the approval process. Sometimes the email is a notification, sometimes the email contains approval links. The email always contains an HTML table of data.

I shared this thread with the Microsoft engineer assigned to my ticket. I've just sent an email requesting an update and requesting they view this thread again.

[AnnRGM]

The MS rep I'm working with has reviewed this thread and replied to me "I haven’t seen any mentions of an uptick in cases related to this issue you are experiencing." They have a meeting on this topic today with other MS resources. 

@Dharam2 Could you share which dates this occurred on? And what you mean by frequent? Were you able to open a ticket? Thanks.

Again, I'll update this thread if I get more information.

[Anonymous]

Thank you for your efforts, @AnnRGM. 

All of our errors of this type have come from simple Outlook Send an Email, V2 actions.  Re-submitting the workflow from the PA interface ALWAYS works.  We have about 40 simple and frequently-run workflows that just send notifications.  We've had about 20 of these errors (on 4 or 5 different workflows) since 11/3, including one so far today.    

[nerfherder]

@AnnRGM / @Dharam2 / @Anonymous / @binki-dcx - I am using the same "connection" (api key?) across 80+ flows. I used to have about a dozen options under "My connections" here and would spread them out across flows. I stopped doing that when I realized I didn't need to, but now I'm reconsidering and thinking maybe this is a design flaw we can correct by splitting the work of our flows across multiple connections? Not sure, haven't had a failure yet today (related to this), have refreshed the credentials on my one connection but experienced another type R failure after.

[binki-dcx]

I am quite certain that sharing a connection is unrelated to this issue. I encountered the error and my account has very little activity. Making more connections when you don’t need to means more maintenance/work for you…

[David_Pezzoli]

Hi folks, it's time to open a ticket to Microsoft about this generic error. At the moment I think it is the only solution.