Forum Discussion
How does a pipeline developer inspect details when encountering 400/4xx and 500/5xx errors
OK, now I figured out how that other suggestion was supposed to work. You have to begin with a "REST" source type, not HttpServer.
When using "REST" source types, then the connection and activity will reflect that. See below.At this point, it allows us to access the full body of the failure like so:
@string(activity('ABC').output)Moreover, we don't actually need to set a variable, since the U/I now displays the full body from the 400-response failures.It isn't clear to me WHY the full failure body is retrieved via "REST" copy-activities but not "HttpServer" copy-activities. If anybody has any insight into the differences, please let me know!FYI, We aren't currently using REST by default because it wasn't enabling us to make binary-to-binary copies for some reason. Whereas HttpServer allows these copy activities and seemed more straightforward. In any event, it does NOT seem like low-code users of ADF should be forced to sacrifice the content-body of these 400 errors, when they are selecting between the sources of type "REST" and "HttpServer". I'd love to know why this issue is happening.
I found a suggestion online that did not work.
The suggestion can be found here:
https://learn.microsoft.com/en-us/answers/questions/778258/getting-web-activity-server-response-error-message
The proposal involved having a failure step, after the web copy-activity, and assigning a variable like so:
Unfortunately the output that is retrieved is no better than before. It does not contain the detailed body that was provided in the contents of the HTTP 400 response. So I'm still looking for an approach that will actually work .
OK, now I figured out how that other suggestion was supposed to work. You have to begin with a "REST" source type, not HttpServer.
When using "REST" source types, then the connection and activity will reflect that. See below.
At this point, it allows us to access the full body of the failure like so: