Add log spans using thread local storage in tests by joostjager · Pull Request #4287 · lightningdevkit/rust-lightning

joostjager · 2025-12-16T11:00:33Z

This is a stripped-down version of #4223 where only the spans are stored in thread local storage. This is a test-only change - the span functionality is compiled out in non-test builds, so there is no impact on production code or no-std users.

Example log output:

std-spans.log

node 2 TRACE [lightning::chain::channelmonitor:4263] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Updating ChannelMonitor with latest holder commitment transaction info [p:0355f8]
node 2 DEBUG [lightning::chain::chainmonitor:1451] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Persistence of ChannelMonitorUpdate id 5 completed [p:0355f8]
node 2 DEBUG [lightning::ln::channelmanager:11589] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Channel is open and awaiting update, resuming it [p:0355f8]
node 2 DEBUG [lightning::ln::channel:9488] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Restored monitor updating in channel d9d065715d1cbe419a5cddaa8b1b749e00acc5a747c7d08165767d1225770bcd resulting in no commitment update and an RAA, with commitment first [p:0355f8]
node 2 TRACE [lightning::ln::channelmanager:9838] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Handling channel resumption with an RAA, no commitment update, 0 pending forwards, 0 pending update_add_htlcs, not broadcasting funding, without channel ready, without announcement, without tx_signatures, without tx_abort [p:0355f8]
node 1 TRACE [lightning::ln::channel:8670] ch:d9d065 [Reconnect nodes B and C] Updating HTLCs on receipt of RAA... [p:02888f]
node 1 TRACE [lightning::ln::channel:8703] ch:d9d065 [Reconnect nodes B and C] ...removing outbound AwaitingRemovedRemoteRevoke 66687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925 [p:02888f]
node 1 DEBUG [lightning::ln::channel:8962] ch:d9d065 [Reconnect nodes B and C] Received a valid revoke_and_ack with no reply necessary. Holding monitor update 5. [p:02888f]
node 1 TRACE [lightning::ln::channelmanager:10054] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] ChannelMonitor updated to 5. 0 pending in-flight updates. [p:027f92]
node 1 TRACE [lightning::ln::channelmanager:10092] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Channel is closed, applying 2 post-update actions [p:027f92]
node 1 DEBUG [lightning::ln::channelmanager:13975] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Unlocking monitor updating and updating monitor [p:02888f]
node 1 TRACE [lightning::chain::chainmonitor:1407] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor to id 5 [p:02888f]
node 1 INFO [lightning::chain::channelmonitor:4226] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Applying update, bringing update_id from 4 to 5 with 1 change(s). [p:02888f]
node 1 TRACE [lightning::chain::channelmonitor:4311] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor with commitment secret [p:02888f]

ldk-reviews-bot · 2025-12-16T11:00:35Z

👋 Hi! This PR is now in draft status.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

codecov · 2025-12-16T14:01:04Z

Codecov Report

❌ Patch coverage is 87.50000% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.61%. Comparing base (09b3bef) to head (1756ae4).
⚠️ Report is 443 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning-macros/src/lib.rs	75.00%	5 Missing and 1 partial ⚠️
lightning/src/util/logger.rs	94.28%	1 Missing and 1 partial ⚠️
lightning/src/util/test_utils.rs	92.30%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4287 +/- ##
==========================================
- Coverage 86.61% 86.61% -0.01% 
==========================================
Files 158 158 Lines 102730 102801 +71 Branches 102730 102801 +71 ==========================================
+ Hits 88984 89045 +61 - Misses 11328 11338 +10 
Partials 2418 2418

Flag	Coverage Δ
fuzzing	`37.19% <13.33%> (+0.99%)`	⬆️
tests	`85.91% <87.50%> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

joostjager · 2026-01-13T10:50:53Z

Rebased and fixed a std/no_std compilation issue with the logging macros.

The problem was that Record::new had a conditional spans parameter only present with std, but #[cfg] checks in macros are evaluated in the calling crate's context, not lightning's. This caused argument count mismatches when crates like lightning-rapid-gossip-sync were compiled without std while lightning had it enabled.

Fixed by making Record::new always take a Spans type that is Vec<&'static str> with std and () (zero-sized) without, and adding a get_tls_spans() helper compiled inside lightning where the cfg correctly reflects its features.

joostjager · 2026-01-13T10:53:06Z

Taking this out of draft as I'm committed to adding span support, but putting it on hold while an alternative approach is being investigated: using proc-macros to transparently augment every method with an implicit logger parameter, which would allow passing the span stack through that invisible parameter instead of relying on TLS.

ldk-reviews-bot · 2026-01-15T10:55:01Z

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Introduces LoggerScope, a RAII guard that pushes span names onto a thread-local stack. In test builds with std, log messages are prefixed with the current span chain (e.g., "[outer->inner]") for easier debugging. Includes: - LoggerScope struct with automatic cleanup on drop - #[log_scope] proc macro to annotate functions with a logging context - test_scope! macro for manual scope changes within long test functions Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

joostjager · 2026-01-19T13:46:49Z

Updated PR to be test-only.

ldk-reviews-bot · 2026-01-19T13:47:46Z

🔔 2nd Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2026-01-19T13:50:18Z

Need to decide on what level the spans are most helpful, where to apply #[log_scope] in main. Aside from what devs may add ad-hoc during testing.

TheBlueMatt

Might want to wait until we decide on #4322 since we'll want to re-use the proc-macro from there if we move forward. I guess they could move forward separately and just merge the macros on whichever lands second.

TheBlueMatt · 2026-01-19T14:04:24Z

 	/// [`ChannelCloseMinimum`]: crate::chain::chaininterface::ConfirmationTarget::ChannelCloseMinimum
 	/// [`NonAnchorChannelFee`]: crate::chain::chaininterface::ConfirmationTarget::NonAnchorChannelFee
 	/// [`SendShutdown`]: MessageSendEvent::SendShutdown
+	#[log_scope]


Can we just use a single proc macro that also scopes sub-functions? If this is for tests presumably that's more useful and also less clutter.

Wasn't sure indeed if we want to manually decide what useful spans are, or we can simply auto-annotate all pub fns, and do a few more perhaps manually if they are called frequently in tests.

Hmm, kinda up to you given you have the most experience with using it, I suppose. Definitely we should automate pub fns, but up to you if you want to automate all fns or make it explicit. ISTM I'm always trying to do a full trace including non-public fns, but if you have a different experience alright.

I am a bit worried about presentation. Full trace might become a pretty long log line

joostjager · 2026-02-24T08:10:37Z

This PR demonstrates that we can DIY a part of what tracing offers, but there is a lot that we are missing out on:

Structured key-value fields on spans and log events
Dynamic per-module/per-span log filtering at runtime
Automatic span timing for performance profiling
Async-aware context propagation across .await points
OpenTelemetry/Jaeger export for distributed tracing
Multiple concurrent subscribers (e.g. stdout + metrics + tracing)
Integration with the broader Rust ecosystem (eg tokio emitting tracing spans natively)

And last but not least:

No need to pass a logger instance through every struct and function signature

All of this to avoid unsafe code on specific no_std platforms. I am still not sold on the trade-off.

joostjager · 2026-03-20T15:09:23Z

I don't see this happening as long as we keep the current logging system

joostjager · 2025-12-16T11:00:33Z

This is a stripped-down version of #4223 where only the spans are stored in thread local storage. This is a test-only change - the span functionality is compiled out in non-test builds, so there is no impact on production code or no-std users.

Example log output:

std-spans.log

node 2 TRACE [lightning::chain::channelmonitor:4263] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Updating ChannelMonitor with latest holder commitment transaction info [p:0355f8]
node 2 DEBUG [lightning::chain::chainmonitor:1451] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Persistence of ChannelMonitorUpdate id 5 completed [p:0355f8]
node 2 DEBUG [lightning::ln::channelmanager:11589] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Channel is open and awaiting update, resuming it [p:0355f8]
node 2 DEBUG [lightning::ln::channel:9488] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Restored monitor updating in channel d9d065715d1cbe419a5cddaa8b1b749e00acc5a747c7d08165767d1225770bcd resulting in no commitment update and an RAA, with commitment first [p:0355f8]
node 2 TRACE [lightning::ln::channelmanager:9838] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Handling channel resumption with an RAA, no commitment update, 0 pending forwards, 0 pending update_add_htlcs, not broadcasting funding, without channel ready, without announcement, without tx_signatures, without tx_abort [p:0355f8]
node 1 TRACE [lightning::ln::channel:8670] ch:d9d065 [Reconnect nodes B and C] Updating HTLCs on receipt of RAA... [p:02888f]
node 1 TRACE [lightning::ln::channel:8703] ch:d9d065 [Reconnect nodes B and C] ...removing outbound AwaitingRemovedRemoteRevoke 66687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925 [p:02888f]
node 1 DEBUG [lightning::ln::channel:8962] ch:d9d065 [Reconnect nodes B and C] Received a valid revoke_and_ack with no reply necessary. Holding monitor update 5. [p:02888f]
node 1 TRACE [lightning::ln::channelmanager:10054] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] ChannelMonitor updated to 5. 0 pending in-flight updates. [p:027f92]
node 1 TRACE [lightning::ln::channelmanager:10092] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Channel is closed, applying 2 post-update actions [p:027f92]
node 1 DEBUG [lightning::ln::channelmanager:13975] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Unlocking monitor updating and updating monitor [p:02888f]
node 1 TRACE [lightning::chain::chainmonitor:1407] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor to id 5 [p:02888f]
node 1 INFO [lightning::chain::channelmonitor:4226] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Applying update, bringing update_id from 4 to 5 with 1 change(s). [p:02888f]
node 1 TRACE [lightning::chain::channelmonitor:4311] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor with commitment secret [p:02888f]

ldk-reviews-bot · 2025-12-16T11:00:35Z

👋 Hi! This PR is now in draft status.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

codecov · 2025-12-16T14:01:04Z

Codecov Report

❌ Patch coverage is 87.50000% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.61%. Comparing base (09b3bef) to head (1756ae4).
⚠️ Report is 443 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning-macros/src/lib.rs	75.00%	5 Missing and 1 partial ⚠️
lightning/src/util/logger.rs	94.28%	1 Missing and 1 partial ⚠️
lightning/src/util/test_utils.rs	92.30%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4287 +/- ##
==========================================
- Coverage 86.61% 86.61% -0.01% 
==========================================
Files 158 158 Lines 102730 102801 +71 Branches 102730 102801 +71 ==========================================
+ Hits 88984 89045 +61 - Misses 11328 11338 +10 
Partials 2418 2418

Flag	Coverage Δ
fuzzing	`37.19% <13.33%> (+0.99%)`	⬆️
tests	`85.91% <87.50%> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

joostjager · 2026-01-13T10:50:53Z

Rebased and fixed a std/no_std compilation issue with the logging macros.

The problem was that Record::new had a conditional spans parameter only present with std, but #[cfg] checks in macros are evaluated in the calling crate's context, not lightning's. This caused argument count mismatches when crates like lightning-rapid-gossip-sync were compiled without std while lightning had it enabled.

Fixed by making Record::new always take a Spans type that is Vec<&'static str> with std and () (zero-sized) without, and adding a get_tls_spans() helper compiled inside lightning where the cfg correctly reflects its features.

joostjager · 2026-01-13T10:53:06Z

Taking this out of draft as I'm committed to adding span support, but putting it on hold while an alternative approach is being investigated: using proc-macros to transparently augment every method with an implicit logger parameter, which would allow passing the span stack through that invisible parameter instead of relying on TLS.

ldk-reviews-bot · 2026-01-15T10:55:01Z

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Introduces LoggerScope, a RAII guard that pushes span names onto a thread-local stack. In test builds with std, log messages are prefixed with the current span chain (e.g., "[outer->inner]") for easier debugging. Includes: - LoggerScope struct with automatic cleanup on drop - #[log_scope] proc macro to annotate functions with a logging context - test_scope! macro for manual scope changes within long test functions Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

joostjager · 2026-01-19T13:46:49Z

Updated PR to be test-only.

ldk-reviews-bot · 2026-01-19T13:47:46Z

🔔 2nd Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2026-01-19T13:50:18Z

Need to decide on what level the spans are most helpful, where to apply #[log_scope] in main. Aside from what devs may add ad-hoc during testing.

TheBlueMatt

Might want to wait until we decide on #4322 since we'll want to re-use the proc-macro from there if we move forward. I guess they could move forward separately and just merge the macros on whichever lands second.

TheBlueMatt · 2026-01-19T14:04:24Z

 	/// [`ChannelCloseMinimum`]: crate::chain::chaininterface::ConfirmationTarget::ChannelCloseMinimum
 	/// [`NonAnchorChannelFee`]: crate::chain::chaininterface::ConfirmationTarget::NonAnchorChannelFee
 	/// [`SendShutdown`]: MessageSendEvent::SendShutdown
+	#[log_scope]


Can we just use a single proc macro that also scopes sub-functions? If this is for tests presumably that's more useful and also less clutter.

Wasn't sure indeed if we want to manually decide what useful spans are, or we can simply auto-annotate all pub fns, and do a few more perhaps manually if they are called frequently in tests.

Hmm, kinda up to you given you have the most experience with using it, I suppose. Definitely we should automate pub fns, but up to you if you want to automate all fns or make it explicit. ISTM I'm always trying to do a full trace including non-public fns, but if you have a different experience alright.

I am a bit worried about presentation. Full trace might become a pretty long log line

joostjager · 2026-02-24T08:10:37Z

This PR demonstrates that we can DIY a part of what tracing offers, but there is a lot that we are missing out on:

Structured key-value fields on spans and log events
Dynamic per-module/per-span log filtering at runtime
Automatic span timing for performance profiling
Async-aware context propagation across .await points
OpenTelemetry/Jaeger export for distributed tracing
Multiple concurrent subscribers (e.g. stdout + metrics + tracing)
Integration with the broader Rust ecosystem (eg tokio emitting tracing spans natively)

And last but not least:

No need to pass a logger instance through every struct and function signature

All of this to avoid unsafe code on specific no_std platforms. I am still not sold on the trade-off.

joostjager · 2026-03-20T15:09:23Z

I don't see this happening as long as we keep the current logging system

joostjager · 2025-12-16T11:00:33Z

This is a stripped-down version of #4223 where only the spans are stored in thread local storage. This is a test-only change - the span functionality is compiled out in non-test builds, so there is no impact on production code or no-std users.

Example log output:

std-spans.log

node 2 TRACE [lightning::chain::channelmonitor:4263] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Updating ChannelMonitor with latest holder commitment transaction info [p:0355f8]
node 2 DEBUG [lightning::chain::chainmonitor:1451] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Persistence of ChannelMonitorUpdate id 5 completed [p:0355f8]
node 2 DEBUG [lightning::ln::channelmanager:11589] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Channel is open and awaiting update, resuming it [p:0355f8]
node 2 DEBUG [lightning::ln::channel:9488] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Restored monitor updating in channel d9d065715d1cbe419a5cddaa8b1b749e00acc5a747c7d08165767d1225770bcd resulting in no commitment update and an RAA, with commitment first [p:0355f8]
node 2 TRACE [lightning::ln::channelmanager:9838] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Handling channel resumption with an RAA, no commitment update, 0 pending forwards, 0 pending update_add_htlcs, not broadcasting funding, without channel ready, without announcement, without tx_signatures, without tx_abort [p:0355f8]
node 1 TRACE [lightning::ln::channel:8670] ch:d9d065 [Reconnect nodes B and C] Updating HTLCs on receipt of RAA... [p:02888f]
node 1 TRACE [lightning::ln::channel:8703] ch:d9d065 [Reconnect nodes B and C] ...removing outbound AwaitingRemovedRemoteRevoke 66687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925 [p:02888f]
node 1 DEBUG [lightning::ln::channel:8962] ch:d9d065 [Reconnect nodes B and C] Received a valid revoke_and_ack with no reply necessary. Holding monitor update 5. [p:02888f]
node 1 TRACE [lightning::ln::channelmanager:10054] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] ChannelMonitor updated to 5. 0 pending in-flight updates. [p:027f92]
node 1 TRACE [lightning::ln::channelmanager:10092] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Channel is closed, applying 2 post-update actions [p:027f92]
node 1 DEBUG [lightning::ln::channelmanager:13975] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Unlocking monitor updating and updating monitor [p:02888f]
node 1 TRACE [lightning::chain::chainmonitor:1407] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor to id 5 [p:02888f]
node 1 INFO [lightning::chain::channelmonitor:4226] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Applying update, bringing update_id from 4 to 5 with 1 change(s). [p:02888f]
node 1 TRACE [lightning::chain::channelmonitor:4311] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor with commitment secret [p:02888f]

ldk-reviews-bot · 2025-12-16T11:00:35Z

👋 Hi! This PR is now in draft status.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

codecov · 2025-12-16T14:01:04Z

Codecov Report

❌ Patch coverage is 87.50000% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.61%. Comparing base (09b3bef) to head (1756ae4).
⚠️ Report is 443 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning-macros/src/lib.rs	75.00%	5 Missing and 1 partial ⚠️
lightning/src/util/logger.rs	94.28%	1 Missing and 1 partial ⚠️
lightning/src/util/test_utils.rs	92.30%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4287 +/- ##
==========================================
- Coverage 86.61% 86.61% -0.01% 
==========================================
Files 158 158 Lines 102730 102801 +71 Branches 102730 102801 +71 ==========================================
+ Hits 88984 89045 +61 - Misses 11328 11338 +10 
Partials 2418 2418

Flag	Coverage Δ
fuzzing	`37.19% <13.33%> (+0.99%)`	⬆️
tests	`85.91% <87.50%> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

joostjager · 2026-01-13T10:50:53Z

Rebased and fixed a std/no_std compilation issue with the logging macros.

The problem was that Record::new had a conditional spans parameter only present with std, but #[cfg] checks in macros are evaluated in the calling crate's context, not lightning's. This caused argument count mismatches when crates like lightning-rapid-gossip-sync were compiled without std while lightning had it enabled.

Fixed by making Record::new always take a Spans type that is Vec<&'static str> with std and () (zero-sized) without, and adding a get_tls_spans() helper compiled inside lightning where the cfg correctly reflects its features.

joostjager · 2026-01-13T10:53:06Z

Taking this out of draft as I'm committed to adding span support, but putting it on hold while an alternative approach is being investigated: using proc-macros to transparently augment every method with an implicit logger parameter, which would allow passing the span stack through that invisible parameter instead of relying on TLS.

ldk-reviews-bot · 2026-01-15T10:55:01Z

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Introduces LoggerScope, a RAII guard that pushes span names onto a thread-local stack. In test builds with std, log messages are prefixed with the current span chain (e.g., "[outer->inner]") for easier debugging. Includes: - LoggerScope struct with automatic cleanup on drop - #[log_scope] proc macro to annotate functions with a logging context - test_scope! macro for manual scope changes within long test functions Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

joostjager · 2026-01-19T13:46:49Z

Updated PR to be test-only.

ldk-reviews-bot · 2026-01-19T13:47:46Z

🔔 2nd Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2026-01-19T13:50:18Z

Need to decide on what level the spans are most helpful, where to apply #[log_scope] in main. Aside from what devs may add ad-hoc during testing.

TheBlueMatt

Might want to wait until we decide on #4322 since we'll want to re-use the proc-macro from there if we move forward. I guess they could move forward separately and just merge the macros on whichever lands second.

TheBlueMatt · 2026-01-19T14:04:24Z

 	/// [`ChannelCloseMinimum`]: crate::chain::chaininterface::ConfirmationTarget::ChannelCloseMinimum
 	/// [`NonAnchorChannelFee`]: crate::chain::chaininterface::ConfirmationTarget::NonAnchorChannelFee
 	/// [`SendShutdown`]: MessageSendEvent::SendShutdown
+	#[log_scope]


Can we just use a single proc macro that also scopes sub-functions? If this is for tests presumably that's more useful and also less clutter.

Wasn't sure indeed if we want to manually decide what useful spans are, or we can simply auto-annotate all pub fns, and do a few more perhaps manually if they are called frequently in tests.

Hmm, kinda up to you given you have the most experience with using it, I suppose. Definitely we should automate pub fns, but up to you if you want to automate all fns or make it explicit. ISTM I'm always trying to do a full trace including non-public fns, but if you have a different experience alright.

I am a bit worried about presentation. Full trace might become a pretty long log line

joostjager · 2026-02-24T08:10:37Z

This PR demonstrates that we can DIY a part of what tracing offers, but there is a lot that we are missing out on:

Structured key-value fields on spans and log events
Dynamic per-module/per-span log filtering at runtime
Automatic span timing for performance profiling
Async-aware context propagation across .await points
OpenTelemetry/Jaeger export for distributed tracing
Multiple concurrent subscribers (e.g. stdout + metrics + tracing)
Integration with the broader Rust ecosystem (eg tokio emitting tracing spans natively)

And last but not least:

No need to pass a logger instance through every struct and function signature

All of this to avoid unsafe code on specific no_std platforms. I am still not sold on the trade-off.

joostjager · 2026-03-20T15:09:23Z

I don't see this happening as long as we keep the current logging system

joostjager · 2025-12-16T11:00:33Z

This is a stripped-down version of #4223 where only the spans are stored in thread local storage. This is a test-only change - the span functionality is compiled out in non-test builds, so there is no impact on production code or no-std users.

Example log output:

std-spans.log

node 2 TRACE [lightning::chain::channelmonitor:4263] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Updating ChannelMonitor with latest holder commitment transaction info [p:0355f8]
node 2 DEBUG [lightning::chain::chainmonitor:1451] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Persistence of ChannelMonitorUpdate id 5 completed [p:0355f8]
node 2 DEBUG [lightning::ln::channelmanager:11589] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Channel is open and awaiting update, resuming it [p:0355f8]
node 2 DEBUG [lightning::ln::channel:9488] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Restored monitor updating in channel d9d065715d1cbe419a5cddaa8b1b749e00acc5a747c7d08165767d1225770bcd resulting in no commitment update and an RAA, with commitment first [p:0355f8]
node 2 TRACE [lightning::ln::channelmanager:9838] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Handling channel resumption with an RAA, no commitment update, 0 pending forwards, 0 pending update_add_htlcs, not broadcasting funding, without channel ready, without announcement, without tx_signatures, without tx_abort [p:0355f8]
node 1 TRACE [lightning::ln::channel:8670] ch:d9d065 [Reconnect nodes B and C] Updating HTLCs on receipt of RAA... [p:02888f]
node 1 TRACE [lightning::ln::channel:8703] ch:d9d065 [Reconnect nodes B and C] ...removing outbound AwaitingRemovedRemoteRevoke 66687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925 [p:02888f]
node 1 DEBUG [lightning::ln::channel:8962] ch:d9d065 [Reconnect nodes B and C] Received a valid revoke_and_ack with no reply necessary. Holding monitor update 5. [p:02888f]
node 1 TRACE [lightning::ln::channelmanager:10054] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] ChannelMonitor updated to 5. 0 pending in-flight updates. [p:027f92]
node 1 TRACE [lightning::ln::channelmanager:10092] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Channel is closed, applying 2 post-update actions [p:027f92]
node 1 DEBUG [lightning::ln::channelmanager:13975] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Unlocking monitor updating and updating monitor [p:02888f]
node 1 TRACE [lightning::chain::chainmonitor:1407] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor to id 5 [p:02888f]
node 1 INFO [lightning::chain::channelmonitor:4226] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Applying update, bringing update_id from 4 to 5 with 1 change(s). [p:02888f]
node 1 TRACE [lightning::chain::channelmonitor:4311] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor with commitment secret [p:02888f]

ldk-reviews-bot · 2025-12-16T11:00:35Z

👋 Hi! This PR is now in draft status.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

codecov · 2025-12-16T14:01:04Z

Codecov Report

❌ Patch coverage is 87.50000% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.61%. Comparing base (09b3bef) to head (1756ae4).
⚠️ Report is 443 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning-macros/src/lib.rs	75.00%	5 Missing and 1 partial ⚠️
lightning/src/util/logger.rs	94.28%	1 Missing and 1 partial ⚠️
lightning/src/util/test_utils.rs	92.30%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4287 +/- ##
==========================================
- Coverage 86.61% 86.61% -0.01% 
==========================================
Files 158 158 Lines 102730 102801 +71 Branches 102730 102801 +71 ==========================================
+ Hits 88984 89045 +61 - Misses 11328 11338 +10 
Partials 2418 2418

Flag	Coverage Δ
fuzzing	`37.19% <13.33%> (+0.99%)`	⬆️
tests	`85.91% <87.50%> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

joostjager · 2026-01-13T10:50:53Z

Rebased and fixed a std/no_std compilation issue with the logging macros.

The problem was that Record::new had a conditional spans parameter only present with std, but #[cfg] checks in macros are evaluated in the calling crate's context, not lightning's. This caused argument count mismatches when crates like lightning-rapid-gossip-sync were compiled without std while lightning had it enabled.

Fixed by making Record::new always take a Spans type that is Vec<&'static str> with std and () (zero-sized) without, and adding a get_tls_spans() helper compiled inside lightning where the cfg correctly reflects its features.

joostjager · 2026-01-13T10:53:06Z

Taking this out of draft as I'm committed to adding span support, but putting it on hold while an alternative approach is being investigated: using proc-macros to transparently augment every method with an implicit logger parameter, which would allow passing the span stack through that invisible parameter instead of relying on TLS.

ldk-reviews-bot · 2026-01-15T10:55:01Z

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Introduces LoggerScope, a RAII guard that pushes span names onto a thread-local stack. In test builds with std, log messages are prefixed with the current span chain (e.g., "[outer->inner]") for easier debugging. Includes: - LoggerScope struct with automatic cleanup on drop - #[log_scope] proc macro to annotate functions with a logging context - test_scope! macro for manual scope changes within long test functions Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

joostjager · 2026-01-19T13:46:49Z

Updated PR to be test-only.

ldk-reviews-bot · 2026-01-19T13:47:46Z

🔔 2nd Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2026-01-19T13:50:18Z

Need to decide on what level the spans are most helpful, where to apply #[log_scope] in main. Aside from what devs may add ad-hoc during testing.

TheBlueMatt

Might want to wait until we decide on #4322 since we'll want to re-use the proc-macro from there if we move forward. I guess they could move forward separately and just merge the macros on whichever lands second.

TheBlueMatt · 2026-01-19T14:04:24Z

 	/// [`ChannelCloseMinimum`]: crate::chain::chaininterface::ConfirmationTarget::ChannelCloseMinimum
 	/// [`NonAnchorChannelFee`]: crate::chain::chaininterface::ConfirmationTarget::NonAnchorChannelFee
 	/// [`SendShutdown`]: MessageSendEvent::SendShutdown
+	#[log_scope]


Can we just use a single proc macro that also scopes sub-functions? If this is for tests presumably that's more useful and also less clutter.

Wasn't sure indeed if we want to manually decide what useful spans are, or we can simply auto-annotate all pub fns, and do a few more perhaps manually if they are called frequently in tests.

Hmm, kinda up to you given you have the most experience with using it, I suppose. Definitely we should automate pub fns, but up to you if you want to automate all fns or make it explicit. ISTM I'm always trying to do a full trace including non-public fns, but if you have a different experience alright.

I am a bit worried about presentation. Full trace might become a pretty long log line

joostjager · 2026-02-24T08:10:37Z

This PR demonstrates that we can DIY a part of what tracing offers, but there is a lot that we are missing out on:

Structured key-value fields on spans and log events
Dynamic per-module/per-span log filtering at runtime
Automatic span timing for performance profiling
Async-aware context propagation across .await points
OpenTelemetry/Jaeger export for distributed tracing
Multiple concurrent subscribers (e.g. stdout + metrics + tracing)
Integration with the broader Rust ecosystem (eg tokio emitting tracing spans natively)

And last but not least:

No need to pass a logger instance through every struct and function signature

All of this to avoid unsafe code on specific no_std platforms. I am still not sold on the trade-off.

joostjager · 2026-03-20T15:09:23Z

I don't see this happening as long as we keep the current logging system

joostjager · 2025-12-16T11:00:33Z

This is a stripped-down version of #4223 where only the spans are stored in thread local storage. This is a test-only change - the span functionality is compiled out in non-test builds, so there is no impact on production code or no-std users.

Example log output:

std-spans.log

node 2 TRACE [lightning::chain::channelmonitor:4263] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Updating ChannelMonitor with latest holder commitment transaction info [p:0355f8]
node 2 DEBUG [lightning::chain::chainmonitor:1451] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Persistence of ChannelMonitorUpdate id 5 completed [p:0355f8]
node 2 DEBUG [lightning::ln::channelmanager:11589] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Channel is open and awaiting update, resuming it [p:0355f8]
node 2 DEBUG [lightning::ln::channel:9488] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Restored monitor updating in channel d9d065715d1cbe419a5cddaa8b1b749e00acc5a747c7d08165767d1225770bcd resulting in no commitment update and an RAA, with commitment first [p:0355f8]
node 2 TRACE [lightning::ln::channelmanager:9838] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Handling channel resumption with an RAA, no commitment update, 0 pending forwards, 0 pending update_add_htlcs, not broadcasting funding, without channel ready, without announcement, without tx_signatures, without tx_abort [p:0355f8]
node 1 TRACE [lightning::ln::channel:8670] ch:d9d065 [Reconnect nodes B and C] Updating HTLCs on receipt of RAA... [p:02888f]
node 1 TRACE [lightning::ln::channel:8703] ch:d9d065 [Reconnect nodes B and C] ...removing outbound AwaitingRemovedRemoteRevoke 66687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925 [p:02888f]
node 1 DEBUG [lightning::ln::channel:8962] ch:d9d065 [Reconnect nodes B and C] Received a valid revoke_and_ack with no reply necessary. Holding monitor update 5. [p:02888f]
node 1 TRACE [lightning::ln::channelmanager:10054] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] ChannelMonitor updated to 5. 0 pending in-flight updates. [p:027f92]
node 1 TRACE [lightning::ln::channelmanager:10092] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Channel is closed, applying 2 post-update actions [p:027f92]
node 1 DEBUG [lightning::ln::channelmanager:13975] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Unlocking monitor updating and updating monitor [p:02888f]
node 1 TRACE [lightning::chain::chainmonitor:1407] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor to id 5 [p:02888f]
node 1 INFO [lightning::chain::channelmonitor:4226] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Applying update, bringing update_id from 4 to 5 with 1 change(s). [p:02888f]
node 1 TRACE [lightning::chain::channelmonitor:4311] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor with commitment secret [p:02888f]

ldk-reviews-bot · 2025-12-16T11:00:35Z

👋 Hi! This PR is now in draft status.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

codecov · 2025-12-16T14:01:04Z

Codecov Report

❌ Patch coverage is 87.50000% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.61%. Comparing base (09b3bef) to head (1756ae4).
⚠️ Report is 443 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning-macros/src/lib.rs	75.00%	5 Missing and 1 partial ⚠️
lightning/src/util/logger.rs	94.28%	1 Missing and 1 partial ⚠️
lightning/src/util/test_utils.rs	92.30%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4287 +/- ##
==========================================
- Coverage 86.61% 86.61% -0.01% 
==========================================
Files 158 158 Lines 102730 102801 +71 Branches 102730 102801 +71 ==========================================
+ Hits 88984 89045 +61 - Misses 11328 11338 +10 
Partials 2418 2418

Flag	Coverage Δ
fuzzing	`37.19% <13.33%> (+0.99%)`	⬆️
tests	`85.91% <87.50%> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

joostjager · 2026-01-13T10:50:53Z

Rebased and fixed a std/no_std compilation issue with the logging macros.

The problem was that Record::new had a conditional spans parameter only present with std, but #[cfg] checks in macros are evaluated in the calling crate's context, not lightning's. This caused argument count mismatches when crates like lightning-rapid-gossip-sync were compiled without std while lightning had it enabled.

Fixed by making Record::new always take a Spans type that is Vec<&'static str> with std and () (zero-sized) without, and adding a get_tls_spans() helper compiled inside lightning where the cfg correctly reflects its features.

joostjager · 2026-01-13T10:53:06Z

Taking this out of draft as I'm committed to adding span support, but putting it on hold while an alternative approach is being investigated: using proc-macros to transparently augment every method with an implicit logger parameter, which would allow passing the span stack through that invisible parameter instead of relying on TLS.

ldk-reviews-bot · 2026-01-15T10:55:01Z

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Introduces LoggerScope, a RAII guard that pushes span names onto a thread-local stack. In test builds with std, log messages are prefixed with the current span chain (e.g., "[outer->inner]") for easier debugging. Includes: - LoggerScope struct with automatic cleanup on drop - #[log_scope] proc macro to annotate functions with a logging context - test_scope! macro for manual scope changes within long test functions Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

joostjager · 2026-01-19T13:46:49Z

Updated PR to be test-only.

ldk-reviews-bot · 2026-01-19T13:47:46Z

🔔 2nd Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2026-01-19T13:50:18Z

Need to decide on what level the spans are most helpful, where to apply #[log_scope] in main. Aside from what devs may add ad-hoc during testing.

TheBlueMatt

Might want to wait until we decide on #4322 since we'll want to re-use the proc-macro from there if we move forward. I guess they could move forward separately and just merge the macros on whichever lands second.

TheBlueMatt · 2026-01-19T14:04:24Z

 	/// [`ChannelCloseMinimum`]: crate::chain::chaininterface::ConfirmationTarget::ChannelCloseMinimum
 	/// [`NonAnchorChannelFee`]: crate::chain::chaininterface::ConfirmationTarget::NonAnchorChannelFee
 	/// [`SendShutdown`]: MessageSendEvent::SendShutdown
+	#[log_scope]


Can we just use a single proc macro that also scopes sub-functions? If this is for tests presumably that's more useful and also less clutter.

Wasn't sure indeed if we want to manually decide what useful spans are, or we can simply auto-annotate all pub fns, and do a few more perhaps manually if they are called frequently in tests.

Hmm, kinda up to you given you have the most experience with using it, I suppose. Definitely we should automate pub fns, but up to you if you want to automate all fns or make it explicit. ISTM I'm always trying to do a full trace including non-public fns, but if you have a different experience alright.

I am a bit worried about presentation. Full trace might become a pretty long log line

joostjager · 2026-02-24T08:10:37Z

This PR demonstrates that we can DIY a part of what tracing offers, but there is a lot that we are missing out on:

Structured key-value fields on spans and log events
Dynamic per-module/per-span log filtering at runtime
Automatic span timing for performance profiling
Async-aware context propagation across .await points
OpenTelemetry/Jaeger export for distributed tracing
Multiple concurrent subscribers (e.g. stdout + metrics + tracing)
Integration with the broader Rust ecosystem (eg tokio emitting tracing spans natively)

And last but not least:

No need to pass a logger instance through every struct and function signature

All of this to avoid unsafe code on specific no_std platforms. I am still not sold on the trade-off.

joostjager · 2026-03-20T15:09:23Z

I don't see this happening as long as we keep the current logging system

joostjager · 2025-12-16T11:00:33Z

This is a stripped-down version of #4223 where only the spans are stored in thread local storage. This is a test-only change - the span functionality is compiled out in non-test builds, so there is no impact on production code or no-std users.

Example log output:

std-spans.log

node 2 TRACE [lightning::chain::channelmonitor:4263] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Updating ChannelMonitor with latest holder commitment transaction info [p:0355f8]
node 2 DEBUG [lightning::chain::chainmonitor:1451] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Persistence of ChannelMonitorUpdate id 5 completed [p:0355f8]
node 2 DEBUG [lightning::ln::channelmanager:11589] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Channel is open and awaiting update, resuming it [p:0355f8]
node 2 DEBUG [lightning::ln::channel:9488] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Restored monitor updating in channel d9d065715d1cbe419a5cddaa8b1b749e00acc5a747c7d08165767d1225770bcd resulting in no commitment update and an RAA, with commitment first [p:0355f8]
node 2 TRACE [lightning::ln::channelmanager:9838] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Handling channel resumption with an RAA, no commitment update, 0 pending forwards, 0 pending update_add_htlcs, not broadcasting funding, without channel ready, without announcement, without tx_signatures, without tx_abort [p:0355f8]
node 1 TRACE [lightning::ln::channel:8670] ch:d9d065 [Reconnect nodes B and C] Updating HTLCs on receipt of RAA... [p:02888f]
node 1 TRACE [lightning::ln::channel:8703] ch:d9d065 [Reconnect nodes B and C] ...removing outbound AwaitingRemovedRemoteRevoke 66687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925 [p:02888f]
node 1 DEBUG [lightning::ln::channel:8962] ch:d9d065 [Reconnect nodes B and C] Received a valid revoke_and_ack with no reply necessary. Holding monitor update 5. [p:02888f]
node 1 TRACE [lightning::ln::channelmanager:10054] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] ChannelMonitor updated to 5. 0 pending in-flight updates. [p:027f92]
node 1 TRACE [lightning::ln::channelmanager:10092] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Channel is closed, applying 2 post-update actions [p:027f92]
node 1 DEBUG [lightning::ln::channelmanager:13975] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Unlocking monitor updating and updating monitor [p:02888f]
node 1 TRACE [lightning::chain::chainmonitor:1407] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor to id 5 [p:02888f]
node 1 INFO [lightning::chain::channelmonitor:4226] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Applying update, bringing update_id from 4 to 5 with 1 change(s). [p:02888f]
node 1 TRACE [lightning::chain::channelmonitor:4311] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor with commitment secret [p:02888f]

ldk-reviews-bot · 2025-12-16T11:00:35Z

👋 Hi! This PR is now in draft status.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

codecov · 2025-12-16T14:01:04Z

Codecov Report

❌ Patch coverage is 87.50000% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.61%. Comparing base (09b3bef) to head (1756ae4).
⚠️ Report is 443 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning-macros/src/lib.rs	75.00%	5 Missing and 1 partial ⚠️
lightning/src/util/logger.rs	94.28%	1 Missing and 1 partial ⚠️
lightning/src/util/test_utils.rs	92.30%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4287 +/- ##
==========================================
- Coverage 86.61% 86.61% -0.01% 
==========================================
Files 158 158 Lines 102730 102801 +71 Branches 102730 102801 +71 ==========================================
+ Hits 88984 89045 +61 - Misses 11328 11338 +10 
Partials 2418 2418

Flag	Coverage Δ
fuzzing	`37.19% <13.33%> (+0.99%)`	⬆️
tests	`85.91% <87.50%> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

joostjager · 2026-01-13T10:50:53Z

Rebased and fixed a std/no_std compilation issue with the logging macros.

The problem was that Record::new had a conditional spans parameter only present with std, but #[cfg] checks in macros are evaluated in the calling crate's context, not lightning's. This caused argument count mismatches when crates like lightning-rapid-gossip-sync were compiled without std while lightning had it enabled.

Fixed by making Record::new always take a Spans type that is Vec<&'static str> with std and () (zero-sized) without, and adding a get_tls_spans() helper compiled inside lightning where the cfg correctly reflects its features.

joostjager · 2026-01-13T10:53:06Z

Taking this out of draft as I'm committed to adding span support, but putting it on hold while an alternative approach is being investigated: using proc-macros to transparently augment every method with an implicit logger parameter, which would allow passing the span stack through that invisible parameter instead of relying on TLS.

ldk-reviews-bot · 2026-01-15T10:55:01Z

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Introduces LoggerScope, a RAII guard that pushes span names onto a thread-local stack. In test builds with std, log messages are prefixed with the current span chain (e.g., "[outer->inner]") for easier debugging. Includes: - LoggerScope struct with automatic cleanup on drop - #[log_scope] proc macro to annotate functions with a logging context - test_scope! macro for manual scope changes within long test functions Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

joostjager · 2026-01-19T13:46:49Z

Updated PR to be test-only.

ldk-reviews-bot · 2026-01-19T13:47:46Z

🔔 2nd Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2026-01-19T13:50:18Z

Need to decide on what level the spans are most helpful, where to apply #[log_scope] in main. Aside from what devs may add ad-hoc during testing.

TheBlueMatt

Might want to wait until we decide on #4322 since we'll want to re-use the proc-macro from there if we move forward. I guess they could move forward separately and just merge the macros on whichever lands second.

TheBlueMatt · 2026-01-19T14:04:24Z

 	/// [`ChannelCloseMinimum`]: crate::chain::chaininterface::ConfirmationTarget::ChannelCloseMinimum
 	/// [`NonAnchorChannelFee`]: crate::chain::chaininterface::ConfirmationTarget::NonAnchorChannelFee
 	/// [`SendShutdown`]: MessageSendEvent::SendShutdown
+	#[log_scope]


Can we just use a single proc macro that also scopes sub-functions? If this is for tests presumably that's more useful and also less clutter.

Wasn't sure indeed if we want to manually decide what useful spans are, or we can simply auto-annotate all pub fns, and do a few more perhaps manually if they are called frequently in tests.

Hmm, kinda up to you given you have the most experience with using it, I suppose. Definitely we should automate pub fns, but up to you if you want to automate all fns or make it explicit. ISTM I'm always trying to do a full trace including non-public fns, but if you have a different experience alright.

I am a bit worried about presentation. Full trace might become a pretty long log line

joostjager · 2026-02-24T08:10:37Z

This PR demonstrates that we can DIY a part of what tracing offers, but there is a lot that we are missing out on:

Structured key-value fields on spans and log events
Dynamic per-module/per-span log filtering at runtime
Automatic span timing for performance profiling
Async-aware context propagation across .await points
OpenTelemetry/Jaeger export for distributed tracing
Multiple concurrent subscribers (e.g. stdout + metrics + tracing)
Integration with the broader Rust ecosystem (eg tokio emitting tracing spans natively)

And last but not least:

No need to pass a logger instance through every struct and function signature

All of this to avoid unsafe code on specific no_std platforms. I am still not sold on the trade-off.

joostjager · 2026-03-20T15:09:23Z

I don't see this happening as long as we keep the current logging system

joostjager · 2025-12-16T11:00:33Z

This is a stripped-down version of #4223 where only the spans are stored in thread local storage. This is a test-only change - the span functionality is compiled out in non-test builds, so there is no impact on production code or no-std users.

Example log output:

std-spans.log

node 2 TRACE [lightning::chain::channelmonitor:4263] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Updating ChannelMonitor with latest holder commitment transaction info [p:0355f8]
node 2 DEBUG [lightning::chain::chainmonitor:1451] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Persistence of ChannelMonitorUpdate id 5 completed [p:0355f8]
node 2 DEBUG [lightning::ln::channelmanager:11589] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Channel is open and awaiting update, resuming it [p:0355f8]
node 2 DEBUG [lightning::ln::channel:9488] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Restored monitor updating in channel d9d065715d1cbe419a5cddaa8b1b749e00acc5a747c7d08165767d1225770bcd resulting in no commitment update and an RAA, with commitment first [p:0355f8]
node 2 TRACE [lightning::ln::channelmanager:9838] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Handling channel resumption with an RAA, no commitment update, 0 pending forwards, 0 pending update_add_htlcs, not broadcasting funding, without channel ready, without announcement, without tx_signatures, without tx_abort [p:0355f8]
node 1 TRACE [lightning::ln::channel:8670] ch:d9d065 [Reconnect nodes B and C] Updating HTLCs on receipt of RAA... [p:02888f]
node 1 TRACE [lightning::ln::channel:8703] ch:d9d065 [Reconnect nodes B and C] ...removing outbound AwaitingRemovedRemoteRevoke 66687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925 [p:02888f]
node 1 DEBUG [lightning::ln::channel:8962] ch:d9d065 [Reconnect nodes B and C] Received a valid revoke_and_ack with no reply necessary. Holding monitor update 5. [p:02888f]
node 1 TRACE [lightning::ln::channelmanager:10054] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] ChannelMonitor updated to 5. 0 pending in-flight updates. [p:027f92]
node 1 TRACE [lightning::ln::channelmanager:10092] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Channel is closed, applying 2 post-update actions [p:027f92]
node 1 DEBUG [lightning::ln::channelmanager:13975] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Unlocking monitor updating and updating monitor [p:02888f]
node 1 TRACE [lightning::chain::chainmonitor:1407] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor to id 5 [p:02888f]
node 1 INFO [lightning::chain::channelmonitor:4226] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Applying update, bringing update_id from 4 to 5 with 1 change(s). [p:02888f]
node 1 TRACE [lightning::chain::channelmonitor:4311] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor with commitment secret [p:02888f]

ldk-reviews-bot · 2025-12-16T11:00:35Z

👋 Hi! This PR is now in draft status.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

codecov · 2025-12-16T14:01:04Z

Codecov Report

❌ Patch coverage is 87.50000% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.61%. Comparing base (09b3bef) to head (1756ae4).
⚠️ Report is 443 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning-macros/src/lib.rs	75.00%	5 Missing and 1 partial ⚠️
lightning/src/util/logger.rs	94.28%	1 Missing and 1 partial ⚠️
lightning/src/util/test_utils.rs	92.30%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4287 +/- ##
==========================================
- Coverage 86.61% 86.61% -0.01% 
==========================================
Files 158 158 Lines 102730 102801 +71 Branches 102730 102801 +71 ==========================================
+ Hits 88984 89045 +61 - Misses 11328 11338 +10 
Partials 2418 2418

Flag	Coverage Δ
fuzzing	`37.19% <13.33%> (+0.99%)`	⬆️
tests	`85.91% <87.50%> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

joostjager · 2026-01-13T10:50:53Z

Rebased and fixed a std/no_std compilation issue with the logging macros.

The problem was that Record::new had a conditional spans parameter only present with std, but #[cfg] checks in macros are evaluated in the calling crate's context, not lightning's. This caused argument count mismatches when crates like lightning-rapid-gossip-sync were compiled without std while lightning had it enabled.

Fixed by making Record::new always take a Spans type that is Vec<&'static str> with std and () (zero-sized) without, and adding a get_tls_spans() helper compiled inside lightning where the cfg correctly reflects its features.

joostjager · 2026-01-13T10:53:06Z

Taking this out of draft as I'm committed to adding span support, but putting it on hold while an alternative approach is being investigated: using proc-macros to transparently augment every method with an implicit logger parameter, which would allow passing the span stack through that invisible parameter instead of relying on TLS.

ldk-reviews-bot · 2026-01-15T10:55:01Z

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Introduces LoggerScope, a RAII guard that pushes span names onto a thread-local stack. In test builds with std, log messages are prefixed with the current span chain (e.g., "[outer->inner]") for easier debugging. Includes: - LoggerScope struct with automatic cleanup on drop - #[log_scope] proc macro to annotate functions with a logging context - test_scope! macro for manual scope changes within long test functions Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

joostjager · 2026-01-19T13:46:49Z

Updated PR to be test-only.

ldk-reviews-bot · 2026-01-19T13:47:46Z

🔔 2nd Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2026-01-19T13:50:18Z

Need to decide on what level the spans are most helpful, where to apply #[log_scope] in main. Aside from what devs may add ad-hoc during testing.

TheBlueMatt

Might want to wait until we decide on #4322 since we'll want to re-use the proc-macro from there if we move forward. I guess they could move forward separately and just merge the macros on whichever lands second.

TheBlueMatt · 2026-01-19T14:04:24Z

 	/// [`ChannelCloseMinimum`]: crate::chain::chaininterface::ConfirmationTarget::ChannelCloseMinimum
 	/// [`NonAnchorChannelFee`]: crate::chain::chaininterface::ConfirmationTarget::NonAnchorChannelFee
 	/// [`SendShutdown`]: MessageSendEvent::SendShutdown
+	#[log_scope]


Can we just use a single proc macro that also scopes sub-functions? If this is for tests presumably that's more useful and also less clutter.

Wasn't sure indeed if we want to manually decide what useful spans are, or we can simply auto-annotate all pub fns, and do a few more perhaps manually if they are called frequently in tests.

Hmm, kinda up to you given you have the most experience with using it, I suppose. Definitely we should automate pub fns, but up to you if you want to automate all fns or make it explicit. ISTM I'm always trying to do a full trace including non-public fns, but if you have a different experience alright.

I am a bit worried about presentation. Full trace might become a pretty long log line

joostjager · 2026-02-24T08:10:37Z

This PR demonstrates that we can DIY a part of what tracing offers, but there is a lot that we are missing out on:

Structured key-value fields on spans and log events
Dynamic per-module/per-span log filtering at runtime
Automatic span timing for performance profiling
Async-aware context propagation across .await points
OpenTelemetry/Jaeger export for distributed tracing
Multiple concurrent subscribers (e.g. stdout + metrics + tracing)
Integration with the broader Rust ecosystem (eg tokio emitting tracing spans natively)

And last but not least:

No need to pass a logger instance through every struct and function signature

All of this to avoid unsafe code on specific no_std platforms. I am still not sold on the trade-off.

joostjager · 2026-03-20T15:09:23Z

I don't see this happening as long as we keep the current logging system

joostjager · 2025-12-16T11:00:33Z

This is a stripped-down version of #4223 where only the spans are stored in thread local storage. This is a test-only change - the span functionality is compiled out in non-test builds, so there is no impact on production code or no-std users.

Example log output:

std-spans.log

node 2 TRACE [lightning::chain::channelmonitor:4263] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Updating ChannelMonitor with latest holder commitment transaction info [p:0355f8]
node 2 DEBUG [lightning::chain::chainmonitor:1451] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Persistence of ChannelMonitorUpdate id 5 completed [p:0355f8]
node 2 DEBUG [lightning::ln::channelmanager:11589] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Channel is open and awaiting update, resuming it [p:0355f8]
node 2 DEBUG [lightning::ln::channel:9488] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Restored monitor updating in channel d9d065715d1cbe419a5cddaa8b1b749e00acc5a747c7d08165767d1225770bcd resulting in no commitment update and an RAA, with commitment first [p:0355f8]
node 2 TRACE [lightning::ln::channelmanager:9838] ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Handling channel resumption with an RAA, no commitment update, 0 pending forwards, 0 pending update_add_htlcs, not broadcasting funding, without channel ready, without announcement, without tx_signatures, without tx_abort [p:0355f8]
node 1 TRACE [lightning::ln::channel:8670] ch:d9d065 [Reconnect nodes B and C] Updating HTLCs on receipt of RAA... [p:02888f]
node 1 TRACE [lightning::ln::channel:8703] ch:d9d065 [Reconnect nodes B and C] ...removing outbound AwaitingRemovedRemoteRevoke 66687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925 [p:02888f]
node 1 DEBUG [lightning::ln::channel:8962] ch:d9d065 [Reconnect nodes B and C] Received a valid revoke_and_ack with no reply necessary. Holding monitor update 5. [p:02888f]
node 1 TRACE [lightning::ln::channelmanager:10054] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] ChannelMonitor updated to 5. 0 pending in-flight updates. [p:027f92]
node 1 TRACE [lightning::ln::channelmanager:10092] ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Channel is closed, applying 2 post-update actions [p:027f92]
node 1 DEBUG [lightning::ln::channelmanager:13975] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Unlocking monitor updating and updating monitor [p:02888f]
node 1 TRACE [lightning::chain::chainmonitor:1407] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor to id 5 [p:02888f]
node 1 INFO [lightning::chain::channelmonitor:4226] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Applying update, bringing update_id from 4 to 5 with 1 change(s). [p:02888f]
node 1 TRACE [lightning::chain::channelmonitor:4311] ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor with commitment secret [p:02888f]

ldk-reviews-bot · 2025-12-16T11:00:35Z

👋 Hi! This PR is now in draft status.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

codecov · 2025-12-16T14:01:04Z

Codecov Report

❌ Patch coverage is 87.50000% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.61%. Comparing base (09b3bef) to head (1756ae4).
⚠️ Report is 443 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning-macros/src/lib.rs	75.00%	5 Missing and 1 partial ⚠️
lightning/src/util/logger.rs	94.28%	1 Missing and 1 partial ⚠️
lightning/src/util/test_utils.rs	92.30%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4287 +/- ##
==========================================
- Coverage 86.61% 86.61% -0.01% 
==========================================
Files 158 158 Lines 102730 102801 +71 Branches 102730 102801 +71 ==========================================
+ Hits 88984 89045 +61 - Misses 11328 11338 +10 
Partials 2418 2418

Flag	Coverage Δ
fuzzing	`37.19% <13.33%> (+0.99%)`	⬆️
tests	`85.91% <87.50%> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

joostjager · 2026-01-13T10:50:53Z

Rebased and fixed a std/no_std compilation issue with the logging macros.

The problem was that Record::new had a conditional spans parameter only present with std, but #[cfg] checks in macros are evaluated in the calling crate's context, not lightning's. This caused argument count mismatches when crates like lightning-rapid-gossip-sync were compiled without std while lightning had it enabled.

Fixed by making Record::new always take a Spans type that is Vec<&'static str> with std and () (zero-sized) without, and adding a get_tls_spans() helper compiled inside lightning where the cfg correctly reflects its features.

joostjager · 2026-01-13T10:53:06Z

Taking this out of draft as I'm committed to adding span support, but putting it on hold while an alternative approach is being investigated: using proc-macros to transparently augment every method with an implicit logger parameter, which would allow passing the span stack through that invisible parameter instead of relying on TLS.

ldk-reviews-bot · 2026-01-15T10:55:01Z

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Introduces LoggerScope, a RAII guard that pushes span names onto a thread-local stack. In test builds with std, log messages are prefixed with the current span chain (e.g., "[outer->inner]") for easier debugging. Includes: - LoggerScope struct with automatic cleanup on drop - #[log_scope] proc macro to annotate functions with a logging context - test_scope! macro for manual scope changes within long test functions Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

joostjager · 2026-01-19T13:46:49Z

Updated PR to be test-only.

ldk-reviews-bot · 2026-01-19T13:47:46Z

🔔 2nd Reminder

Hey @TheBlueMatt! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

joostjager · 2026-01-19T13:50:18Z

Need to decide on what level the spans are most helpful, where to apply #[log_scope] in main. Aside from what devs may add ad-hoc during testing.

TheBlueMatt

Might want to wait until we decide on #4322 since we'll want to re-use the proc-macro from there if we move forward. I guess they could move forward separately and just merge the macros on whichever lands second.

TheBlueMatt · 2026-01-19T14:04:24Z

 	/// [`ChannelCloseMinimum`]: crate::chain::chaininterface::ConfirmationTarget::ChannelCloseMinimum
 	/// [`NonAnchorChannelFee`]: crate::chain::chaininterface::ConfirmationTarget::NonAnchorChannelFee
 	/// [`SendShutdown`]: MessageSendEvent::SendShutdown
+	#[log_scope]


Can we just use a single proc macro that also scopes sub-functions? If this is for tests presumably that's more useful and also less clutter.

Wasn't sure indeed if we want to manually decide what useful spans are, or we can simply auto-annotate all pub fns, and do a few more perhaps manually if they are called frequently in tests.

Hmm, kinda up to you given you have the most experience with using it, I suppose. Definitely we should automate pub fns, but up to you if you want to automate all fns or make it explicit. ISTM I'm always trying to do a full trace including non-public fns, but if you have a different experience alright.

I am a bit worried about presentation. Full trace might become a pretty long log line

joostjager · 2026-02-24T08:10:37Z

This PR demonstrates that we can DIY a part of what tracing offers, but there is a lot that we are missing out on:

Structured key-value fields on spans and log events
Dynamic per-module/per-span log filtering at runtime
Automatic span timing for performance profiling
Async-aware context propagation across .await points
OpenTelemetry/Jaeger export for distributed tracing
Multiple concurrent subscribers (e.g. stdout + metrics + tracing)
Integration with the broader Rust ecosystem (eg tokio emitting tracing spans natively)

And last but not least:

No need to pass a logger instance through every struct and function signature

All of this to avoid unsafe code on specific no_std platforms. I am still not sold on the trade-off.

joostjager · 2026-03-20T15:09:23Z

I don't see this happening as long as we keep the current logging system

joostjager force-pushed the std-spans branch 2 times, most recently from 38d439b to 5d2f39fCompare December 16, 2025 12:29

joostjager force-pushed the std-spans branch 3 times, most recently from 1355c20 to c3714c6Compare December 18, 2025 10:37

joostjager added this to Weekly Goals Jan 8, 2026

joostjager self-assigned this Jan 8, 2026

joostjager force-pushed the std-spans branch 2 times, most recently from 14f583e to aedfe0aCompare January 13, 2026 10:49

joostjager marked this pull request as ready for review January 13, 2026 10:53

ldk-reviews-bot requested a review from jkczyz January 13, 2026 10:54

joostjager force-pushed the std-spans branch 2 times, most recently from d84cd91 to ee9b3bbCompare January 13, 2026 11:16

joostjager removed the request for review from jkczyz January 15, 2026 11:00

joostjager force-pushed the std-spans branch 2 times, most recently from aba1a33 to e119381Compare January 19, 2026 13:34

joostjagerand others added 3 commits January 19, 2026 14:43

Add log_scope to channelmanager
bb84bd6

Add test logger scope
1756ae4

joostjager force-pushed the std-spans branch from e119381 to 1756ae4Compare January 19, 2026 13:43

joostjager changed the title ~~Add log spans using thread local storage in std~~Add log spans using thread local storage in testsJan 19, 2026

joostjager requested a review from TheBlueMatt January 19, 2026 13:47

TheBlueMatt reviewed Jan 19, 2026
View reviewed changes

joostjager marked this pull request as draft March 5, 2026 12:08

joostjager closed this Mar 20, 2026

github-project-automationBot moved this to Done in Weekly Goals Mar 20, 2026

joostjager force-pushed the std-spans branch 2 times, most recently from 38d439b to 5d2f39fCompare December 16, 2025 12:29

joostjager force-pushed the std-spans branch 3 times, most recently from 1355c20 to c3714c6Compare December 18, 2025 10:37

joostjager added this to Weekly Goals Jan 8, 2026

joostjager self-assigned this Jan 8, 2026

joostjager force-pushed the std-spans branch 2 times, most recently from 14f583e to aedfe0aCompare January 13, 2026 10:49

joostjager marked this pull request as ready for review January 13, 2026 10:53

ldk-reviews-bot requested a review from jkczyz January 13, 2026 10:54

joostjager force-pushed the std-spans branch 2 times, most recently from d84cd91 to ee9b3bbCompare January 13, 2026 11:16

joostjager removed the request for review from jkczyz January 15, 2026 11:00

joostjager force-pushed the std-spans branch 2 times, most recently from aba1a33 to e119381Compare January 19, 2026 13:34

joostjagerand others added 3 commits January 19, 2026 14:43

Add log_scope to channelmanager
bb84bd6

Add test logger scope
1756ae4

joostjager force-pushed the std-spans branch from e119381 to 1756ae4Compare January 19, 2026 13:43

joostjager changed the title ~~Add log spans using thread local storage in std~~Add log spans using thread local storage in testsJan 19, 2026

joostjager requested a review from TheBlueMatt January 19, 2026 13:47

TheBlueMatt reviewed Jan 19, 2026
View reviewed changes

joostjager marked this pull request as draft March 5, 2026 12:08

joostjager closed this Mar 20, 2026

github-project-automationBot moved this to Done in Weekly Goals Mar 20, 2026

joostjager force-pushed the std-spans branch 2 times, most recently from 38d439b to 5d2f39fCompare December 16, 2025 12:29

joostjager force-pushed the std-spans branch 3 times, most recently from 1355c20 to c3714c6Compare December 18, 2025 10:37

joostjager added this to Weekly Goals Jan 8, 2026

joostjager self-assigned this Jan 8, 2026

joostjager force-pushed the std-spans branch 2 times, most recently from 14f583e to aedfe0aCompare January 13, 2026 10:49

joostjager marked this pull request as ready for review January 13, 2026 10:53

ldk-reviews-bot requested a review from jkczyz January 13, 2026 10:54

joostjager force-pushed the std-spans branch 2 times, most recently from d84cd91 to ee9b3bbCompare January 13, 2026 11:16

joostjager removed the request for review from jkczyz January 15, 2026 11:00

joostjager force-pushed the std-spans branch 2 times, most recently from aba1a33 to e119381Compare January 19, 2026 13:34

joostjagerand others added 3 commits January 19, 2026 14:43

Add log_scope to channelmanager
bb84bd6

Add test logger scope
1756ae4

joostjager force-pushed the std-spans branch from e119381 to 1756ae4Compare January 19, 2026 13:43

joostjager changed the title ~~Add log spans using thread local storage in std~~Add log spans using thread local storage in testsJan 19, 2026

joostjager requested a review from TheBlueMatt January 19, 2026 13:47

TheBlueMatt reviewed Jan 19, 2026
View reviewed changes

joostjager marked this pull request as draft March 5, 2026 12:08

joostjager closed this Mar 20, 2026

github-project-automationBot moved this to Done in Weekly Goals Mar 20, 2026

joostjager force-pushed the std-spans branch 2 times, most recently from 38d439b to 5d2f39fCompare December 16, 2025 12:29

joostjager force-pushed the std-spans branch 3 times, most recently from 1355c20 to c3714c6Compare December 18, 2025 10:37

joostjager added this to Weekly Goals Jan 8, 2026

joostjager self-assigned this Jan 8, 2026

joostjager force-pushed the std-spans branch 2 times, most recently from 14f583e to aedfe0aCompare January 13, 2026 10:49

joostjager marked this pull request as ready for review January 13, 2026 10:53

ldk-reviews-bot requested a review from jkczyz January 13, 2026 10:54

joostjager force-pushed the std-spans branch 2 times, most recently from d84cd91 to ee9b3bbCompare January 13, 2026 11:16

joostjager removed the request for review from jkczyz January 15, 2026 11:00

joostjager force-pushed the std-spans branch 2 times, most recently from aba1a33 to e119381Compare January 19, 2026 13:34

joostjagerand others added 3 commits January 19, 2026 14:43

Add log_scope to channelmanager
bb84bd6

Add test logger scope
1756ae4

joostjager force-pushed the std-spans branch from e119381 to 1756ae4Compare January 19, 2026 13:43

joostjager changed the title ~~Add log spans using thread local storage in std~~Add log spans using thread local storage in testsJan 19, 2026

joostjager requested a review from TheBlueMatt January 19, 2026 13:47

TheBlueMatt reviewed Jan 19, 2026
View reviewed changes

joostjager marked this pull request as draft March 5, 2026 12:08

joostjager closed this Mar 20, 2026

github-project-automationBot moved this to Done in Weekly Goals Mar 20, 2026

joostjager force-pushed the std-spans branch 2 times, most recently from 38d439b to 5d2f39fCompare December 16, 2025 12:29

joostjager force-pushed the std-spans branch 3 times, most recently from 1355c20 to c3714c6Compare December 18, 2025 10:37

joostjager added this to Weekly Goals Jan 8, 2026

joostjager self-assigned this Jan 8, 2026

joostjager force-pushed the std-spans branch 2 times, most recently from 14f583e to aedfe0aCompare January 13, 2026 10:49

joostjager marked this pull request as ready for review January 13, 2026 10:53

ldk-reviews-bot requested a review from jkczyz January 13, 2026 10:54

joostjager force-pushed the std-spans branch 2 times, most recently from d84cd91 to ee9b3bbCompare January 13, 2026 11:16

joostjager removed the request for review from jkczyz January 15, 2026 11:00

joostjager force-pushed the std-spans branch 2 times, most recently from aba1a33 to e119381Compare January 19, 2026 13:34

joostjagerand others added 3 commits January 19, 2026 14:43

Add log_scope to channelmanager
bb84bd6

Add test logger scope
1756ae4

joostjager force-pushed the std-spans branch from e119381 to 1756ae4Compare January 19, 2026 13:43

joostjager changed the title ~~Add log spans using thread local storage in std~~Add log spans using thread local storage in testsJan 19, 2026

joostjager requested a review from TheBlueMatt January 19, 2026 13:47

TheBlueMatt reviewed Jan 19, 2026
View reviewed changes

joostjager marked this pull request as draft March 5, 2026 12:08

joostjager closed this Mar 20, 2026

github-project-automationBot moved this to Done in Weekly Goals Mar 20, 2026

joostjager force-pushed the std-spans branch 2 times, most recently from 38d439b to 5d2f39fCompare December 16, 2025 12:29

joostjager force-pushed the std-spans branch 3 times, most recently from 1355c20 to c3714c6Compare December 18, 2025 10:37

joostjager added this to Weekly Goals Jan 8, 2026

joostjager self-assigned this Jan 8, 2026

joostjager force-pushed the std-spans branch 2 times, most recently from 14f583e to aedfe0aCompare January 13, 2026 10:49

joostjager marked this pull request as ready for review January 13, 2026 10:53

ldk-reviews-bot requested a review from jkczyz January 13, 2026 10:54

joostjager force-pushed the std-spans branch 2 times, most recently from d84cd91 to ee9b3bbCompare January 13, 2026 11:16

joostjager removed the request for review from jkczyz January 15, 2026 11:00

joostjager force-pushed the std-spans branch 2 times, most recently from aba1a33 to e119381Compare January 19, 2026 13:34

joostjagerand others added 3 commits January 19, 2026 14:43

Add log_scope to channelmanager
bb84bd6

Add test logger scope
1756ae4

joostjager force-pushed the std-spans branch from e119381 to 1756ae4Compare January 19, 2026 13:43

joostjager changed the title ~~Add log spans using thread local storage in std~~Add log spans using thread local storage in testsJan 19, 2026

joostjager requested a review from TheBlueMatt January 19, 2026 13:47

TheBlueMatt reviewed Jan 19, 2026
View reviewed changes

joostjager marked this pull request as draft March 5, 2026 12:08

joostjager closed this Mar 20, 2026

github-project-automationBot moved this to Done in Weekly Goals Mar 20, 2026

joostjager force-pushed the std-spans branch 2 times, most recently from 38d439b to 5d2f39fCompare December 16, 2025 12:29

joostjager force-pushed the std-spans branch 3 times, most recently from 1355c20 to c3714c6Compare December 18, 2025 10:37

joostjager added this to Weekly Goals Jan 8, 2026

joostjager self-assigned this Jan 8, 2026

joostjager force-pushed the std-spans branch 2 times, most recently from 14f583e to aedfe0aCompare January 13, 2026 10:49

joostjager marked this pull request as ready for review January 13, 2026 10:53

ldk-reviews-bot requested a review from jkczyz January 13, 2026 10:54

joostjager force-pushed the std-spans branch 2 times, most recently from d84cd91 to ee9b3bbCompare January 13, 2026 11:16

joostjager removed the request for review from jkczyz January 15, 2026 11:00

joostjager force-pushed the std-spans branch 2 times, most recently from aba1a33 to e119381Compare January 19, 2026 13:34

joostjagerand others added 3 commits January 19, 2026 14:43

Add log_scope to channelmanager
bb84bd6

Add test logger scope
1756ae4

joostjager force-pushed the std-spans branch from e119381 to 1756ae4Compare January 19, 2026 13:43

joostjager changed the title ~~Add log spans using thread local storage in std~~Add log spans using thread local storage in testsJan 19, 2026

joostjager requested a review from TheBlueMatt January 19, 2026 13:47

TheBlueMatt reviewed Jan 19, 2026
View reviewed changes

joostjager marked this pull request as draft March 5, 2026 12:08

joostjager closed this Mar 20, 2026

github-project-automationBot moved this to Done in Weekly Goals Mar 20, 2026

joostjager force-pushed the std-spans branch 2 times, most recently from 38d439b to 5d2f39fCompare December 16, 2025 12:29

joostjager force-pushed the std-spans branch 3 times, most recently from 1355c20 to c3714c6Compare December 18, 2025 10:37

joostjager added this to Weekly Goals Jan 8, 2026

joostjager self-assigned this Jan 8, 2026

joostjager force-pushed the std-spans branch 2 times, most recently from 14f583e to aedfe0aCompare January 13, 2026 10:49

joostjager marked this pull request as ready for review January 13, 2026 10:53

ldk-reviews-bot requested a review from jkczyz January 13, 2026 10:54

joostjager force-pushed the std-spans branch 2 times, most recently from d84cd91 to ee9b3bbCompare January 13, 2026 11:16

joostjager removed the request for review from jkczyz January 15, 2026 11:00

joostjager force-pushed the std-spans branch 2 times, most recently from aba1a33 to e119381Compare January 19, 2026 13:34

joostjagerand others added 3 commits January 19, 2026 14:43

Add log_scope to channelmanager
bb84bd6

Add test logger scope
1756ae4

joostjager force-pushed the std-spans branch from e119381 to 1756ae4Compare January 19, 2026 13:43

joostjager changed the title ~~Add log spans using thread local storage in std~~Add log spans using thread local storage in testsJan 19, 2026

joostjager requested a review from TheBlueMatt January 19, 2026 13:47

TheBlueMatt reviewed Jan 19, 2026
View reviewed changes

joostjager marked this pull request as draft March 5, 2026 12:08

joostjager closed this Mar 20, 2026

github-project-automationBot moved this to Done in Weekly Goals Mar 20, 2026

Uh oh!

Conversation

joostjager commented Dec 16, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Dec 16, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecovBot commented Dec 16, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

joostjager commented Jan 13, 2026

Uh oh!

joostjager commented Jan 13, 2026

Uh oh!

ldk-reviews-bot commented Jan 15, 2026

Uh oh!

joostjager commented Jan 19, 2026

Uh oh!

ldk-reviews-bot commented Jan 19, 2026

Uh oh!

joostjager commented Jan 19, 2026

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

TheBlueMattJan 19, 2026

Choose a reason for hiding this comment

Uh oh!

joostjagerJan 19, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMattJan 19, 2026

Choose a reason for hiding this comment

Uh oh!

joostjagerJan 19, 2026

Choose a reason for hiding this comment

Uh oh!

joostjager commented Feb 24, 2026

Uh oh!

joostjager commented Mar 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

joostjager commented Dec 16, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Dec 16, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecovBot commented Dec 16, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

joostjager commented Jan 13, 2026

Uh oh!

joostjager commented Jan 13, 2026

Uh oh!

ldk-reviews-bot commented Jan 15, 2026

Uh oh!

joostjager commented Jan 19, 2026

Uh oh!

ldk-reviews-bot commented Jan 19, 2026

Uh oh!

joostjager commented Jan 19, 2026

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

TheBlueMattJan 19, 2026

joostjager commented Dec 16, 2025•
edited
Loading

ldk-reviews-bot commented Dec 16, 2025•
edited
Loading

codecovBot commented Dec 16, 2025•
edited
Loading

joostjagerJan 19, 2026•
edited
Loading

joostjager commented Dec 16, 2025•
edited
Loading

ldk-reviews-bot commented Dec 16, 2025•
edited
Loading

codecovBot commented Dec 16, 2025•
edited
Loading

joostjagerJan 19, 2026•
edited
Loading

joostjager commented Dec 16, 2025•
edited
Loading

ldk-reviews-bot commented Dec 16, 2025•
edited
Loading

codecovBot commented Dec 16, 2025•
edited
Loading

joostjagerJan 19, 2026•
edited
Loading