This was omitted by accident from the original PR, despite
being done in the original perfdata writer connection code.
Without setting this parameter, host name verification will be
disabled, which poses a security risk.
The log message on TLS handshake errors always stated that a client handshake
failed, even if if the connection was acting as the server. The commit changes
it so that the actual role is taken into account.
`strand.running_in_this_thread()` relies on thread-local storage
internally, and may return false positives if the coroutine is resumed
in a different thread than it was suspended in. In debug builds, this is
not problem, since there's no TLS optimization done by the compiler, but
in release builds, the compiler might cache the address of the
thread-local variable read before the coroutine suspension, and thus
potentially reuse the same address in a different thread after
resumption, which would cause `running_in_this_thread()` to return false
or even crash (but we didn't see any crashes related to this). So,
perform the assertion only in debug builds to prevent potential wrong
usages of the `Timeout` class. For more details, see [^1][^2][^3].
[^1]: https://github.com/chriskohlhoff/asio/issues/1366
[^2]: https://bugs.llvm.org/show_bug.cgi?id=19177
[^3]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
Now, the individual `ProcessQueueItem` functions decide whether to
acquire an `olock` or not instead of probing this from within the
worker loop. This is way easier than having to deal with the potential
out of order processing of items in the queue in both ways, i.e., we
don't want to send delete events for objects while their created events
haven't been processed yet and vice versa.
This commit restructures the queue items so that each one now has a method
`GetQueueLookupKey()` that is used to derive which elements of the queue are
considered to be equal. For this, there is a key extractor for the
`multi_index_container` that takes the `variant` from the queue item, calls
that method on it, and puts the result in a second variant type. The types in
that variant type are automatically deduced from the return types of the
individual methods.
Previously, the checkable was locked while processing all the dependency
registration stuff, so the worker thread should also do the same to
avoid any potential race conditions.
As opposed to the previous version which used a complex data structure
to correctly manage the query priorities, this version uses two separate
queues for the high and normal priority writes. All high priority writes
are processed in FIFO order but over take all queries from the normal
priority queue. The later queue only be processed when the high priority
queue is empty.
So that it doesn't cause `request body too large` errors when used with
the default OpenTelemetry Collector config that has `max_request_body_size`
set to `20MiB`.
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']
