The recursion depth limit added to JsonDecode() in 2.16.2 gave the C++
function a second parameter with a default value. Function pointers do not
carry default arguments, so the DSL function binding deduced an arity of 2
via boost::function_types::function_arity and required two arguments. As a
result `Json.decode("...")` failed with "Too few arguments for function",
an undocumented breaking change in a patch release.
Wrap JsonDecode() in a single-argument shim (mirroring the existing
JsonEncodeShim) so the registered function keeps its one-parameter contract
while still applying the default depth limit internally.
refs #10913
Depending on the Boost version, the existing test case based on Boost.Asio
coroutines might use a stack allocated without a guard page and might not
reliably detect an overflow. This commit additionally runs the same test
function within a pthread thread started with the same stack size as used by
our coroutines.
If parsing JSON is rejected due to the depth limit introduced in the last
commit, also include the path (like root["object"]["children"]...) that exceeds
the allowed nesting depth.
Data structures parsed from JSON may be accessed recursively, so deeply nested
structures may wreak havoc by overflowing the stack. Thus, enforce a general
nesting depth limit of 24 by default (which should be more than enough for
reasonable use), with the ability to pass a different limit to JsonDecode() if
needed.
Since perfdata is set once when a check result is created and
never changed again, locking this is unnecessary. This avoids
components unnecessarily waiting on each other when processing
perfdata.
This fixes the locking cascade observed sometimes when the perfdata
writer work queue blocks, where it extends to a lock on the entire
check result eventually, affecting even more components.
This is necessary for parallel test execution so that tests don't overwrite
or delete (destructor of the fixture) data in these directories.
This is implemented by generating a unique name for each test with
`Utility::NewUniqueId()`.
Mostly unrelated change to add the network label to test suites
already touched by other changes in this PR. The label is already
used for the perfdata writer tests to make it easy to exclude tests
that need a network connection when building and testing in a sandbox.
There's a set of two tests for each perfdatawriter, just
to make sure they can connect and send data that looks reasonably
correct, and to make sure pausing actually works while the connection
is stuck.
Then there's a more in-depth suite of tests for PerfdataWriterConnection
itself, to verify that connection handling works well in all types
of scenarios.
Co-authored-by: Yonas Habteab <yonas.habteab@icinga.com>
This doesn't fix any concrete errors in master, but if tests ever get
reordered for some reason and the tlsutility tests run before the
http tests, they will leave broken certificates behind. This could
be solved by cleaning up manually in the tests, but that again could
cause issues if the tlsutility tests ever run in the middle of the
http ones.
The proper solution is using a CTest fixture to establish a dependency
where the tlsutility tests always run before the tests using a new
CTest fixture that provides the cleanup between these test groups.
On Windows, waiting on system timers is notoriously inaccurate, with
short sleeps taking tens of milliseconds longer than specified.
This led to these tests to sporadically fail on the Windows GHAs with
`check 5 == counter has failed [5 != 4]`, because it couldn't get the
expected five invokations within the given tolerance of 50ms.
Currently on master, the tests check if a timer triggers five times
in 550ms with a 100ms interval, only leaving those 50ms to spare.
This commit extends the tolerance of to 75ms. This is a pretty
conservative increase (when we could have gone to 99ms), but it
might be enough to satisfy the windows GHAs.
This commit refactors the ValueGenerator class to be a template that can
work with any container type. Previously, one has to manually take care
of the used container by lazily iterating over it within a lambda. Now,
the `ValueGenerator` class itself takes care of all the iteration,
making it easier to use and less error-prone. The new base `Generator`
class is required to allow the `JsonEncoder` to handle generators in a
type-erased manner.
The dummy command would sometimes fail with a "broken pipe" error
on slow runners like the arm64 container image one, so this commit
replaces them with executing a noop lambda. Using "/bin/echo" might
also have been fine, but with this there isn't even a process spawned
that can get a broken pipe.
Due to the changes in the previous commit, the test-cases for
notitificationcomponent now also pick up LogDebug level messages that
also fit the pattern. To get the test-cases working again a second
pattern is needed to exclude these.
If the logger is started with `Activate()` before `SetActive()`, it won't
log anything, as the logger updates the "min severity" value of loggers
only when starting them, and if they're not active at that point, they
will just be ignored, so the min severity remains at info.
This adds generalized IncomingHttpMessage and OutgoingHttpMessage templates
that support different types of streams (via a std::variant) and can both
be used for either requests or responses.
The tacked on metadata from the old HttpRequest and server connection from
the old HttpServerConnection have been moved to HttpApi(Request|Response)
classes that derive from the above generalized message types.
The race is between `NotificationTimerHandler`, which sends a reminder notification
after a certain inverval during problem states and `SendNotificationsHandler` which
sends out the notifications on state changes.
When the timer handler runs just before a state change triggers a notification, the
timer handler might pick up that state-change before the send notification handler
can set its no_more_notifications flag. In that case a "reminder" notification will
be sent out before the initial one, and despite `interval = 0` on the notification
object.
The certificate generated by `PkiUtility::NewCert()` is self-signed,
and so the subsequent `PkiUtility::SignCsr()` call is required.
However, `PkiUtility::SignCsr()` doesn't reuse existin cert, instead
it'll generate a fresh one on its own. So, skip the first one entirely!
