Sending wrong value for key causes ugly stacktrace

[Crunsher]

When running a query against the API with an existing key but a value of the wrong type, Icinga does not catch the exception but sends it right back at the requestor.

Expected Behavior

A usable error code + message

Current Behavior

From the log, curl returns the stacktrace.

[2017-06-23 09:37:17 +0200] information/ApiListener: New client connection from [127.0.0.1]:38009 (no client certificate)
[2017-06-23 09:37:17 +0200] information/HttpServerConnection: Request: GET /v1/objects/downtimes (from [127.0.0.1]:38009, user: root)
[2017-06-23 09:37:17 +0200] critical/HttpServerConnection: Unhandled exception while processing Http request: Error: Cannot convert value of type 'Boolean' to an object.

	(0) libremote.so.2.6.3: <unknown function> (+0x1196a4) [0x7f2178af66a4]
	(1) libremote.so.2.6.3: <unknown function> (+0x104391) [0x7f2178ae1391]
	(2) libremote.so.2.6.3: _ZNK6icinga5ValuecvN5boost13intrusive_ptrIT_EEINS_5ArrayEEEv (+0xed) [0x7f2178aca44b]
	(3) libremote.so.2.6.3: icinga::ObjectQueryHandler::HandleRequest(boost::intrusive_ptr<icinga::ApiUser> const&, icinga::HttpRequest&, icinga::HttpResponse&, boost::intrusive_ptr<icinga::Dictionary> const&) (+0x2c3) [0x7f2178aac56f]
	(4) libremote.so.2.6.3: icinga::HttpHandler::ProcessRequest(boost::intrusive_ptr<icinga::ApiUser> const&, icinga::HttpRequest&, icinga::HttpResponse&) (+0x523) [0x7f2178aa0077]
	(5) libremote.so.2.6.3: icinga::HttpServerConnection::ProcessMessageAsync(icinga::HttpRequest&) (+0xc2e) [0x7f2178a9e802]
	(6) libremote.so.2.6.3: <unknown function> (+0x189833) [0x7f2178b66833]
	(7) libremote.so.2.6.3: <unknown function> (+0x17ceae) [0x7f2178b59eae]
	(8) libremote.so.2.6.3: <unknown function> (+0x16d801) [0x7f2178b4a801]
	(9) libremote.so.2.6.3: <unknown function> (+0x15a52d) [0x7f2178b3752d]
	(10) libremote.so.2.6.3: <unknown function> (+0x1411ad) [0x7f2178b1e1ad]
	(11) libbase.so.2.6.3: <unknown function> (+0x11541c) [0x7f21795f641c]
	(12) libbase.so.2.6.3: icinga::WorkQueue::WorkerThreadProc() (+0x251) [0x7f21795e46d9]
	(13) libbase.so.2.6.3: <unknown function> (+0x1efbc9) [0x7f21796d0bc9]
	(14) libbase.so.2.6.3: <unknown function> (+0x20882e) [0x7f21796e982e]
	(15) libbase.so.2.6.3: <unknown function> (+0x2058d3) [0x7f21796e68d3]
	(16) libbase.so.2.6.3: <unknown function> (+0x20109a) [0x7f21796e209a]
	(17) libboost_thread.so.1.55.0: <unknown function> (+0xdaea) [0x7f217a3aaaea]
	(18) libpthread.so.0: <unknown function> (+0x8064) [0x7f21799f8064]
	(19) libc.so.6: clone (+0x6d) [0x7f2176e1762d]

Steps to Reproduce (for bugs)

Run this query against your API

$ curl -s -X GET -H 'Accept: application/json' -d '{"attrs":false}' 'https://localhost:5665/v1/objects/downtimes'

Your Environment

• Version used (icinga2 --version):
  version: v2.6.3-308-gc9039e1

[dnsmichi]

How does the client returned body look like?

[Crunsher]

Oh, it's a 503 with the stacktrace. But the formatting is all garbled and it does not really tell a user much. My solution would be to just send the error message and not also send the full stacktrace.

{"error":503.0,"status":"Error: Cannot convert value of type 'Boolean' to an object.\n\n\t(0) libremote.so.2.6.3: <unknown function> (+0x1196a4) [0x7f2178af66a4]\n\t(1) libremote.so.2.6.3: <unknown function> (+0x104391) [0x7f2178ae1391]\n\t(2) libremote.so.2.6.3: _ZNK6icinga5ValuecvN5boost13intrusive_ptrIT_EEINS_5ArrayEEEv (+0xed) [0x7f2178aca44b]\n\t(3) libremote.so.2.6.3: icinga::ObjectQueryHandler::HandleRequest(boost::intrusive_ptr<icinga::ApiUser> const&, icinga::HttpRequest&, icinga::HttpResponse&, boost::intrusive_ptr<icinga::Dictionary> const&) (+0x2c3) [0x7f2178aac56f]\n\t(4) libremote.so.2.6.3: icinga::HttpHandler::ProcessRequest(boost::intrusive_ptr<icinga::ApiUser> const&, icinga::HttpRequest&, icinga::HttpResponse&) (+0x523) [0x7f2178aa0077]\n\t(5) libremote.so.2.6.3: icinga::HttpServerConnection::ProcessMessageAsync(icinga::HttpRequest&) (+0xc2e) [0x7f2178a9e802]\n\t(6) libremote.so.2.6.3: <unknown function> (+0x189833) [0x7f2178b66833]\n\t(7) libremote.so.2.6.3: <unknown function> (+0x17ceae) [0x7f2178b59eae]\n\t(8) libremote.so.2.6.3: <unknown function> (+0x16d801) [0x7f2178b4a801]\n\t(9) libremote.so.2.6.3: <unknown function> (+0x15a52d) [0x7f2178b3752d]\n\t(10) libremote.so.2.6.3: <unknown function> (+0x1411ad) [0x7f2178b1e1ad]\n\t(11) libbase.so.2.6.3: <unknown function> (+0x11541c) [0x7f21795f641c]\n\t(12) libbase.so.2.6.3: icinga::WorkQueue::WorkerThreadProc() (+0x251) [0x7f21795e46d9]\n\t(13) libbase.so.2.6.3: <unknown function> (+0x1efbc9) [0x7f21796d0bc9]\n\t(14) libbase.so.2.6.3: <unknown function> (+0x20882e) [0x7f21796e982e]\n\t(15) libbase.so.2.6.3: <unknown function> (+0x2058d3) [0x7f21796e68d3]\n\t(16) libbase.so.2.6.3: <unknown function> (+0x20109a) [0x7f21796e209a]\n\t(17) libboost_thread.so.1.55.0: <unknown function> (+0xdaea) [0x7f217a3aaaea]\n\t(18) libpthread.so.0: <unknown function> (+0x8064) [0x7f21799f8064]\n\t(19) libc.so.6: clone (+0x6d) [0x7f2176e1762d]\n\n"}

[dnsmichi]

AFAIK we agreed to send the stacktrace with new lines inside the error message body, as this sometimes is useful. That was before release 2.4 AFAIK.

Still it is not optimal - a proper formatted error message makes sense. Sometimes you'd also need the verbose information.

Didn't we introduce "verbose" as global flag somewhere? Could be the reason that this is not always applied, and you'll receive the verbose output all the time.

[Stefar77]

Change remote/objectqueryhandler.cpp :: HandleRequest to fix it.

   Array::Ptr uattrs = params->Get("attrs");

   Array::Ptr uattrs;
        try {
                uattrs = params->Get("attrs");
        } catch (...){
                HttpUtility::SendJsonError(response, 503, "Invalid parameters");
                return true;
        }

[Stefar77]

Added this to my fix / repo

[Crunsher]

Much better ^_^
But it'd be nice to have a more specific error message than "Invalid paramters", "Error: Cannot convert value of type 'Boolean' to an object" for example should be in the exceptions text.

[Stefar77]

@Crunsher This was indeed quick and dirty.. :-)
I'm on it, found a better way by checking dictionary but I noticed later I need to do that for all 3 variables..

I'm still a JSON noob; my test was wrong so I reverted to try / catch because I failed to make a working array: ["Lol"]

When I check type it always seem to fail, and I'm pretty sure I did the test array wrong but I run aNag on my phone that uses the API and it also fails when I check for type Array or Dict.

Is this okay for now?

[dnsmichi]

I'll pick your fix into a separate PR from #5419 :) Please create separate PRs for different topics next time, your work is much appreciated and it makes our lives easier for reviews 👍

[dnsmichi]

curl -k -s -u root:icinga -X GET -H 'Accept: application/json' -d '{"attrs":false}' 'https://localhost:5665/v1/objects/downtimes'
{"error":400.0,"status":"Invalid type for 'attrs' attribute specified. Array type is required."}