mirror of
https://github.com/ZmnSCPxj/clboss.git
synced 2026-08-14 12:43:19 +02:00
7fa87c01e7
Adds periodic askrene-age against the persistent clboss-xrebalance
layer so capacity constraints written by inform_channel_constrained
do not accumulate forever. Mirrors FundsMover's age_clboss_layer:
fires on Msg::TimerRandomHourly, logs num_removed at Debug, and
catches RpcError with -32601 stayed at Debug (graceful degradation
on CLN without askrene-age) while other codes promote to Warn so
sustained aging failure is visible.
The aging cutoff is controlled by a new plugin option,
clboss-xrebalance-age-secs, default 3600 (1h) to match FundsMover's
production value. Operators on networks with slower flows (signet)
are expected to widen this; the right value is empirical and will
be tuned after observation.
The option is registered dynamic=true so the window is mutable at
runtime via:
lightning-cli setconfig clboss-xrebalance-age-secs <secs>
No clboss / lightningd restart required.
To support that, three small infrastructure pieces:
* Boss::Msg::ManifestOption gains a bool dynamic field (default
false; preserves existing behavior).
* Boss::Mod::Manifester emits the per-option dynamic flag in the
getmanifest response, so lightningd knows to forward setconfig
for that option.
* New Boss::Mod::SetConfigHandler module records (name -> dynamic
flag) from Msg::ManifestOption events, then handles incoming
Msg::CommandRequest where command == "setconfig" by validating
the named option is registered + dynamic and re-raising a fresh
Msg::Option on the bus. Existing option handlers re-apply the
new value transparently.
Contract for any future opt-in to dynamic: at startup lightningd
encodes Int / Bool / Flag option values as JSON primitives, but at
setconfig time it encodes them as JSON strings. Handlers for
dynamic options must accept both Jsmn shapes. The XMoveFunds
option handler does this; the contract is documented in
SetConfigHandler's header comment so future modules can opt in
safely.
53 lines
1.7 KiB
C++
53 lines
1.7 KiB
C++
#ifndef BOSS_MOD_SETCONFIGHANDLER_HPP
|
|
#define BOSS_MOD_SETCONFIGHANDLER_HPP
|
|
|
|
#include<map>
|
|
#include<string>
|
|
|
|
namespace S { class Bus; }
|
|
|
|
namespace Boss { namespace Mod {
|
|
|
|
/** class Boss::Mod::SetConfigHandler
|
|
*
|
|
* @brief Dispatches `setconfig` JSON-RPC calls from lightningd
|
|
* for options that were registered with `dynamic = true` on their
|
|
* Msg::ManifestOption.
|
|
*
|
|
* Lightningd routes `setconfig <name> <val>` to the plugin that
|
|
* owns the option, as a JSON-RPC method call. We turn that into
|
|
* a fresh Msg::Option on the bus, so existing option handlers
|
|
* re-apply the new value without a plugin restart.
|
|
*
|
|
* Contract for module authors who mark an option `dynamic = true`:
|
|
* at startup lightningd delivers Int / Bool / Flag option values
|
|
* as JSON primitives, but at setconfig time lightningd encodes the
|
|
* value as a JSON string. Any module that opts in to dynamic
|
|
* updates MUST tolerate both shapes in its Msg::Option handler --
|
|
* inspect `o.value.is_string()` and parse from the string form
|
|
* when appropriate.
|
|
*/
|
|
class SetConfigHandler {
|
|
private:
|
|
S::Bus& bus;
|
|
/* Name -> dynamic flag, populated from Msg::ManifestOption
|
|
* events during the Manifestation phase. Non-dynamic
|
|
* options are recorded too so we can return a clearer error
|
|
* than "unknown option" if lightningd ever forwards a
|
|
* setconfig for a non-dynamic name (which it should not). */
|
|
std::map<std::string, bool> options;
|
|
|
|
void start();
|
|
|
|
public:
|
|
SetConfigHandler() =delete;
|
|
SetConfigHandler(SetConfigHandler&&) =delete;
|
|
SetConfigHandler(SetConfigHandler const&) =delete;
|
|
|
|
explicit
|
|
SetConfigHandler(S::Bus& bus_) : bus(bus_) { start(); }
|
|
};
|
|
|
|
}}
|
|
|
|
#endif /* !defined(BOSS_MOD_SETCONFIGHANDLER_HPP) */
|