I am currently using a Power Automate Workflow titled “Post to a channel when a webhook request is received.” I’ve encountered an issue where large messages cause a “413 Entity Too Large” error. While I can see the error details on the Power Automate Workflow history page, I’m unable to retrieve this information directly from the HTTP response in my code. Instead, it returns only a “202 Accepted” response.
Here’s a snippet of the code I’m using to send the request:
using (HttpClient client = new HttpClient(handler)) {
if (teamsChannelSettings.TeamsWebHook != null)
{
client.BaseAddress = new Uri(teamsChannelSettings.TeamsWebHook);
}
HttpRequestMessage request = new HttpRequestMessage(HttpMethod.Post, string.Empty)
{
Content = new StringContent(adaptiveCardJsonString, Encoding.UTF8, "application/json")
};
HttpResponseMessage response = client.SendAsync(request).Result;
return response; }
Here is the response I get when the request is too large:
StatusCode: 202, ReasonPhrase: ‘Accepted’, Version: 1.1, Content: System.Net.Http.StreamContent, Headers: { Pragma: no-cache
x-ms-workflow-run-id: 08584804860707094154508038074CU195
x-ms-correlation-id: 447ddbe5-fc59-460a-84b6-21913634758e
x-ms-client-tracking-id: 08584804860707094154508038074CU195
x-ms-trigger-history-name: 08584804860707094154508038074CU195
x-ms-execution-location: westeurope x-ms-workflow-system-id:
/locations/westeurope/scaleunits/prod-14/workflows/25eb736c4dfe441983f6bdcdeb8628b7
x-ms-workflow-id: 25eb736c4dfe441983f6bdcdeb8628b7
x-ms-workflow-version: 08584805743398174085 x-ms-workflow-name:
396dce14-048f-44ed-af42-83c393f34330 x-ms-tracking-id:
447ddbe5-fc59-460a-84b6-21913634758e
x-ms-ratelimit-burst-remaining-workflow-writes: 68
x-ms-ratelimit-remaining-workflow-download-contentsize: 49556480
x-ms-ratelimit-remaining-workflow-upload-contentsize: 49492340
x-ms-ratelimit-time-remaining-directapirequests: 4615247
x-ms-request-id: westeurope:447ddbe5-fc59-460a-84b6-21913634758e
Strict-Transport-Security: max-age=31536000; includeSubDomains
Cache-Control: no-cache Date: Tue, 16 Jul 2024 09:06:54 GMT
Content-Length: 0 Expires: -1 }
We are receiving the same response for various failure cases, such as when the Adaptive Card JSON format is incorrect. Therefore, I need to determine the specific reason for the failure in the response. So that I can shrink the message in case of 413 EntityTooLarge issue
How can I programmatically retrieve detailed error information, such as “413 Entity Too Large” or JSON format errors, directly from the HTTP response? Any guidance on capturing and handling such errors would be greatly appreciated.
3
If you goal is to implement error handling based on ‘413 EntityTooLarge’, I suggest looking into the following functionalities.
-
Create a new shape after the “Post your own adaptive card..” action with a run after “failed”.
-
In this shape extract the previous action’s input/output, this contains the error message. Use the actions expression:
actions(‘HTTP’)
Return an action’s output at runtime, or values from other JSON
name-and-value pairs, which you can assign to an expression.
https://learn.microsoft.com/en-us/azure/logic-apps/workflow-definition-language-functions-reference#actions
Sample:
It’s a little difficult to give you the exact answer but I can give you the building blocks that you can use to put it all together.
first() Expression
You’ll need to pull out the first adaptive card JSON from your payload. Reason being, it complicates the process if you loop.
Use a compose() action and the first() expression to transform your array to an object which will be your adaptive card an then pass the result of that into the action that creates the card in the Teams channel.
Response Action
You’ll get a 202 unless you provide a structured response, this action will give you that.
Create two Response actions, one when an error occurs and one for successful results.
The output from the Teams action will given you the ability to feedback the response to the calling application via the Body of the response.
Depending on what you want in your C# app, you may want to set the Error response code to 400 so it fails on response, up to you.
This is just a mock up but shows the concept at the bottom when it comes to catching the errors.
If you want to show a different outcome in the PA logs, then use a terminate after the error response with either a Cancelled or Error code.