RedisDisconnected::what() and RedisProtocolError::what() always returned an
empty string. Similarly, BadRedisType::what() and BadRedisInt::what() only
return the value that couldn't be parsed without any information about the
exception type. If only what() is used when printing the exception, as it's
typical, this results in unhelpful log messages like the following when simply
stopping the Redis server:
[2026-02-23 14:33:33 +0100] critical/IcingaDB: Error during receiving the response to a query which has been fired and forgotten: Connection reset by peer [system:104 at /usr/include/boost/asio/detail/reactive_socket_recv_op.hpp:134 in function 'do_complete']
[2026-02-23 14:33:33 +0100] critical/IcingaDB: Error during receiving the response to a query which has been fired and forgotten:
[2026-02-23 14:33:33 +0100] critical/IcingaDB: Error during receiving the response to a query which has been fired and forgotten:
[2026-02-23 14:33:33 +0100] critical/IcingaDB: Cannot connect to redis-1:6379: Connection refused [system:111 at /usr/include/boost/asio/detail/reactive_socket_connect_op.hpp:98 in function 'do_complete']
This commit changes these messages so that something like "Redis disconnected",
"Redis protocol error: bad int: foo", or "Redis protocol error: bad type: ?" is
returned. In doing so, it also removes a member of type std::vector<char> in
BadRedisInt as this is unsafe to use in exceptions (it violates the requirement
that copy constructor and assignment must be nothrow, see
https://en.cppreference.com/w/cpp/error/exception.html#Standard_exception_requirements).
With this commit, the log messages are now a bit more helpful:
[2026-02-23 15:08:23 +0100] critical/IcingaDB: Error during receiving the response to a query which has been fired and forgotten: Connection reset by peer [system:104 at /usr/include/boost/asio/detail/reactive_socket_recv_op.hpp:134 in function 'do_complete']
[2026-02-23 15:08:23 +0100] critical/IcingaDB: Error during receiving the response to a query which has been fired and forgotten: Redis disconnected
[2026-02-23 15:08:23 +0100] critical/IcingaDB: Error during receiving the response to a query which has been fired and forgotten: Redis disconnected
[2026-02-23 15:08:23 +0100] critical/IcingaDB: Cannot connect to redis-1:6379: Connection refused [system:111 at /usr/include/boost/asio/detail/reactive_socket_connect_op.hpp:98 in function 'do_complete']
This change just gives clear ownership over the CpuBoundWork to the
OutgoingHttpMessage, instead of the previous shared_ptr and weak_ptr
combination with an unclear purpose.
This is inefficient and involves possible bad surprises regarding
waiting durations on busy nodes. Instead, use `AsioConditionVariable#Wait()`
if there are no free slots. It's notified by others'
`CpuBoundWork#~CpuBoundWork()` once finished.
so that `/v1/events` doesn't have to use `IoBoundWorkSlot`.
`IoBoundWorkSlot#~IoBoundWorkSlot()` will wait for a free semaphore slot
which will be almost immediately released by `CpuBoundWork#~CpuBoundWork()`.
Just releasing the already aquired slot manually is more efficient.
Without this change, it is easy to pass a temporary, for example a vector
returned by a function to ParallelFor(). With this commit a type-constraint
is added to disable the use of this function for rvalue sequences.
An alternative would have been to capture rvalue-references in the function,
but that would have made the function unnecessarily complex, involving tuple-capture
and `shared_ptr`s, while it is usually easy to control lifetime at the call-site.
This also enables the use of the function with "containers" that
don't have a size function but implement an overload for `std::size()`,
like c-arrays with fixed sizes.
Previously this didn't print which of host/service is referenced
and what the referenced non-existing checkable's name should have
been.
This commit adds that information.
If there are such requests, without this change, they would all be allowed and
processed, resulting in unsafe concurrent (write) access to these data
structures, which can ultimately crash the daemon or lead to other unintended
behavior.
Especially our history messages contain lots of hardcoded C string literals
`"like this one"`. At runtime, they get translated to pointers to constant
global memory, `const char*`. String `malloc(3)`s and copies these data every
time. In contrast, the new type just stores the address if any. (Actually,
`const char*` is wrapped by `std::string_view` to not compute its length every
time.)
So that when we want the query stats of this specific connection we can
easily get them, since the session leader contains the aggregated stats
of all its children.
InfluxDB seems to always include some other metadata in the `Content-Type`
header separated by semicolons like `application/json; charset=utf-8`,
and comparing the whole string with `application/json` will always fail,
resulting in almost always useless warnings without any helpful information
for the user what actually went wrong.
