Commit 9abbb084 authored by Iustin Pop's avatar Iustin Pop
Browse files

Fix error reporting for bad Luxi arguments in QueryD



Currently, the query daemon would simply close the connection to the
client without issuing a response, if parsing the arguments failed;
the error was just logged.

Since this is very ugly from the client's point of view, we change it
so that the error is both logged and sent back to the
client. Furthermore, the execution block reporting is also cleaned up
a bit, to make the code more uniform.
Signed-off-by: default avatarIustin Pop <iustin@google.com>
Reviewed-by: default avatarAgata Murawska <agatamurawska@google.com>
parent c12a68e2
......@@ -139,9 +139,10 @@ handleClientMsg client creader args = do
call_result <- handleCallWrapper cfg args
(!status, !rval) <-
case call_result of
Bad x -> do
logWarning $ "Failed to execute request: " ++ x
return (False, JSString $ J.toJSString x)
Bad err -> do
let errmsg = "Failed to execute request: " ++ err
logWarning errmsg
return (False, showJSON errmsg)
Ok result -> do
logDebug $ "Result " ++ show (pp_value result)
return (True, result)
......@@ -159,8 +160,11 @@ handleClient client creader = do
return False
RecvOk payload ->
case validateCall payload >>= decodeCall of
Bad err -> logWarning ("Failed to parse request: " ++ err) >>
return False
Bad err -> do
let errmsg = "Failed to parse request: " ++ err
logWarning errmsg
sendMsg client $ buildResponse False (showJSON errmsg)
return False
Ok args -> handleClientMsg client creader args
-- | Main client loop: runs one loop of 'handleClient', and if that
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment