CHANGELOG.md: note that we broke custom rust notifications.
What the developer wrote
Authored by Rusty Russell
CHANGELOG.md: note that we broke custom rust notifications.
Sorry :(
We chose to update our own few custom plugin notifications by manually creating the deprecated
fields and adding the new ones, rather than having lightningd fix them up. But this didn't apply
to other plugins which might issue their own notifications: in particular, this hit @daywalker90.
Simply documenting this is lazy, but we're close to release and I don't expect anyone else to
be affected.
Reported-by: @daywalker90
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
What changed, and why it matters
This is a documentation-only commit adding a note to the changelog. It records that a recent code change altered the JSON format for custom notifications sent by Rust plugins in Core Lightning. The change broke compatibility for third-party Rust plugins that issue their own notifications, because fields are no longer wrapped in a 'payload' object and 'origin' moved outside the 'params' object. There is no security vulnerability here—only an API compatibility issue that may cause plugins to break or behave unexpectedly until updated.
No security patch is required. Users and developers of Rust plugins that rely on custom notifications should update their code to expect fields directly (not inside 'payload') and to look for 'origin' outside 'params'). Operators should review plugin compatibility before upgrading to the affected release. No CVE or advisory is warranted for this compatibility break.
Security signals we found
No code changes—documentation-only changelog entry
Breaking API/ABI change in plugin notification format
Potential operational impact: third-party Rust plugins may fail to parse custom notifications
No evidence of memory corruption, privilege escalation, or cryptographic weakness
Evidence from the diff
The commit adds a single line to CHANGELOG.md disclosing a breaking change in the custom notification format for Rust plugins. Previously, custom notification fields were wrapped in a ‘payload’ object and ‘origin’ was inside ‘params’; after the change, fields are at the top level and ‘origin’ is outside ‘params’. This is a backward-compatibility break for plugins that emit custom notifications, not a memory-safety, cryptographic, or authorization flaw. The commit message explicitly states the team chose not to have lightningd automatically fix up the old format for other plugins, opting to document the break instead.
Changed components
Core Lightning Rust plugin notification APIThird-party Rust plugins that emit custom notificationsInspect captured patch +1 / −0
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 90a6e518..69afd156 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -48,6 +48,7 @@ Note: release schedule moved one month: this is v25.09, and all deprecations inc
- libplugin: you can now call the synchronous API functions at any time (not just in the init callback). ([#8410])
- Plugins: "utxo_deposit" notification is allowed to have missing `transfer_from`, and null is not considered an account name. ([#8410])
- Plugins: `sql` tables `forwards`, `htlcs`, `invoices`, `sendpays` all use `created_index` as their primary key (and `rowid` is now an alias to this). ([#8410])
+ - Rust: custom notifications fields no longer wrapped in `payload` object, and `origin` is now outside the `params` object ([#8376])
### Deprecated
Why this scored 20/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.