Handle error code properly
As part of the previous patch tests, UpdateService shows this bug, where
on a multipart parser failure, the dbus match object gets instantiated,
and eventually fails. This leads to mediocre logging, and possibly
could leave update service in an undesirable state.
Fix the error by moving the conditional up.
Tested:
Filling a 16MB file with all zeros and sending it now no longer logs
that a monitor has been set up, and returns immediately instead of
waiting for timeout.
```
dd if=/dev/zero of=zeros-file bs=1048576 count=16 of=16mb.txt
curl -k --location POST https://192.168.7.2/redfish/v1/UpdateService/update -F 'UpdateParameters={"Targets":[]} ;type=application/json' -H "Expect:" --user "root:0penBmc" -F UpdateFile=@16mb.txt -v
```
Change-Id: I0962d15c624936b4fa199a675123702003dd697b
Signed-off-by: Ed Tanous <ed@tanous.net>
diff --git a/redfish-core/lib/update_service.hpp b/redfish-core/lib/update_service.hpp
index 14f8ecf..0418d26 100644
--- a/redfish-core/lib/update_service.hpp
+++ b/redfish-core/lib/update_service.hpp
@@ -668,6 +668,7 @@
inline void
updateMultipartContext(const std::shared_ptr<bmcweb::AsyncResp>& asyncResp,
+ const crow::Request& req,
const MultipartParser& parser)
{
const std::string* uploadData = nullptr;
@@ -754,6 +755,9 @@
setApplyTime(asyncResp, *applyTime);
+ // Setup callback for when new software detected
+ monitorForSoftwareAvailable(asyncResp, req, "/redfish/v1/UpdateService");
+
uploadImageFile(asyncResp->res, *uploadData);
}
@@ -783,10 +787,6 @@
{
MultipartParser parser;
- // Setup callback for when new software detected
- monitorForSoftwareAvailable(asyncResp, req,
- "/redfish/v1/UpdateService");
-
ParserError ec = parser.parse(req);
if (ec != ParserError::PARSER_SUCCESS)
{
@@ -796,7 +796,8 @@
messages::internalError(asyncResp->res);
return;
}
- updateMultipartContext(asyncResp, parser);
+
+ updateMultipartContext(asyncResp, req, parser);
}
else
{