Revert "bookkeeper: don't flood logs if we have many channelmoves all at once."
What the developer wrote
Authored by Rusty Russell
Revert "bookkeeper: don't flood logs if we have many channelmoves all at once."
This reverts commit 1dda0c07530d01dfa50f6121ba30530659a1475b so we can test
what its like to be flooded with logs again.
This benefits from other improvements we've made this release, to handling
plugin input (i.e. converting to use common/jsonrpc_io), so this doesn't
make much difference.
tests/test_coinmoves.py::test_generate_coinmoves (100,000, sqlite3):
Time (from start to end of l2 node): 211 seconds
Worst latency: 108 seconds
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
What changed, and why it matters
This commit removes a small log-throttling feature in Core Lightning's bookkeeper plugin. Previously, if many channel balance updates arrived at once, the plugin only logged the first and last one to avoid spamming debug logs. This change reverts that behavior so every update is logged again. The author says this is acceptable because other performance improvements this release make the flood less of a problem. There is no direct security vulnerability here; the main effect is more debug log output, which could slightly increase disk use or log-noise under heavy load.
No immediate security action required. Operators who rely on compact debug logs under heavy channel activity may notice increased log volume. If log flooding becomes problematic in production, consider re-applying the throttling or adjusting log levels. Reviewers should confirm the performance claim (211s/108s worst latency) holds on their target deployment.
Security signals we found
Reversion of a log-flooding mitigation
Increased debug log volume under high channel-move load
No input validation, memory safety, or authorization changes
Evidence from the diff
The patch reverts commit 1dda0c07530d01dfa50f6121ba30530659a1475b. It removes the conditional logging logic in plugins/bkpr/bookkeeper.c that limited per-channelmove debug logging to the first and last entries when more than two channelmoves were returned. The parse_and_log_channel_move function loses its bool log parameter, and listchannelmoves_done now calls it for every array element unconditionally. The author notes that switching plugin I/O to common/jsonrpc_io mitigates the original flooding concern, and a benchmark (test_generate_coinmoves with 100,000 moves) completes in 211 seconds with 108-second worst latency.
Changed components
plugins/bkpr/bookkeeper.cparse_and_log_channel_move()listchannelmoves_done()Inspect captured patch +8 / −18
diff --git a/plugins/bkpr/bookkeeper.c b/plugins/bkpr/bookkeeper.c
index 21ec62a9..57948311 100644
--- a/plugins/bkpr/bookkeeper.c
+++ b/plugins/bkpr/bookkeeper.c
@@ -84,8 +84,7 @@ static void
parse_and_log_channel_move(struct command *cmd,
const char *buf,
const jsmntok_t *channelmove,
- struct refresh_info *rinfo,
- bool log);
+ struct refresh_info *rinfo);
static struct command_result *datastore_done(struct command *cmd,
const char *method,
@@ -118,15 +117,8 @@ static struct command_result *listchannelmoves_done(struct command *cmd,
be64 be_index;
moves = json_get_member(buf, result, "channelmoves");
- if (moves->size > 2) {
- plugin_log(cmd->plugin, LOG_DBG,
- "%u channelmoves, only logging first and last",
- moves->size);
- }
-
json_for_each_arr(i, t, moves)
- parse_and_log_channel_move(cmd, buf, t, rinfo,
- i == 0 || i == moves->size - 1);
+ parse_and_log_channel_move(cmd, buf, t, rinfo);
be_index = cpu_to_be64(bkpr->channelmoves_index);
jsonrpc_set_datastore_binary(cmd, "bookkeeper/channelmoves_index",
@@ -1268,8 +1260,7 @@ static void
parse_and_log_channel_move(struct command *cmd,
const char *buf,
const jsmntok_t *channelmove,
- struct refresh_info *rinfo,
- bool log)
+ struct refresh_info *rinfo)
{
struct channel_event *e = tal(cmd, struct channel_event);
struct account *acct;
@@ -1316,12 +1307,11 @@ parse_and_log_channel_move(struct command *cmd,
err = tal_free(err);
}
- if (log)
- plugin_log(cmd->plugin, LOG_DBG, "coin_move 2 (%s) %s -%s %s %"PRIu64,
- e->tag,
- fmt_amount_msat(tmpctx, e->credit),
- fmt_amount_msat(tmpctx, e->debit),
- CHANNEL_MOVE, e->timestamp);
+ plugin_log(cmd->plugin, LOG_DBG, "coin_move 2 (%s) %s -%s %s %"PRIu64,
+ e->tag,
+ fmt_amount_msat(tmpctx, e->credit),
+ fmt_amount_msat(tmpctx, e->debit),
+ CHANNEL_MOVE, e->timestamp);
/* Go find the account for this event */
acct = find_account(bkpr, acct_name);
Why this scored 18/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.