ec0bfe521d
MetricsRegistry did two jobs. It owned the OTel metrics pipeline, and it registered the observable gauges whose callbacks read live application services. The second job is what made the whole class xrpld-tier, so the pipeline's lifecycle -- the recording() gate and the stop() teardown that closes a use-after-free window -- could not be unit-tested in xrpl_tests. Split it in two: - xrpl::telemetry::MetricsRegistry (libxrpl) owns the exporter, provider, meter, the 16 synchronous instruments, recording(), stop(), and the record*/increment* methods. - xrpl::telemetry::AppMetricGauges (xrpld) owns the 19 observable gauges and their callbacks, holding a reference to the core and to the ServiceRegistry. MetricMacros.h and ValidationTracker move with the core. The macros need only recording() and meter(), both core members; the core holds a tracker by value, and a libxrpl header cannot include one from src/. ApplicationImp owns both objects and sequences them. The core is built in the member-init list, so every synchronous instrument exists before any subsystem can record one. The gauges are armed once overlay_ exists, the last service their callbacks read. Shutdown detaches the gauge callbacks before the core drops the provider, and each shutdown step is isolated so a failure in one cannot skip the others. That detach call is new. detachCallbacks() had no callers, and the flag it sets is read by the gauge callbacks but can no longer be written by the core, so the caller now has to make the ordering explicit. The telemetry module links xrpl.libxrpl.core and xrpl.libxrpl.protocol PUBLIC: ValidationTracker.h takes a LedgerIndex and MetricMacros.h takes a ServiceRegistry, both in interfaces a consumer compiles against. Adds a MetricsRegistry gtest that drives an enabled core with telemetry on and pins the recording() gate, stop() leaving the registry inert, and stop() being idempotent. The libxrpl test tree no longer depends on xrpld.telemetry at all, and the two CMake workarounds that compiled xrpld sources into xrpl_tests are gone. Documentation and dashboard source links follow the code to their new paths, split between the two classes by which one now defines each metric.
Unit Tests
Running Tests
Unit tests are bundled in the xrpld executable and can be executed using the
--unittest parameter. Without any arguments to this option, all non-manual
unit tests will be executed. If you want to run one or more manual tests, you
must specify it by suite or full-name (e.g. xrpl.app.NoRippleCheckLimits or
just NoRippleCheckLimits).
More than one suite or group of suites can be specified as a comma separated
list via the argument. For example, --unittest=beast,OversizeMeta will run
all suites in the beast library (root identifier) as well as the test suite
named OversizeMeta). All name matches are case sensitive.
Tests can be executed in parallel using several child processes by specifying
the --unittest-jobs=N parameter. The default behavior is to execute serially
using a single process.
The order that suites are executed is determined by the suite priority that
is optionally specified when the suite is declared in the code with one of the
BEAST_DEFINE_TESTSUITE macros. By default, suites have a priority of 0, and
other suites can choose to declare an integer priority value to make themselves
execute before or after other suites based on their specified priority value.
By default, the framework will emit the name of each testcase/testsuite when it
starts and any messages sent to the suite log stream. The --quiet option will
suppress both types of messages, but combining --unittest-log with --quiet
will cause log messages to be emitted while suite/case names are suppressed.