AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 21 Bitcoin

pyln-testing: don't let wait_for_log match its own forwarded announcement

Public commit record

What the developer wrote

Authored by Ken Sedgwick

100/100 · Strong
pyln-testing: don't let wait_for_log match its own forwarded announcement

An inline plugin's Plugin() object lives in the test process, and
Plugin() installs a PluginLogHandler on the root logger so that a
plugin author's logging calls reach lightningd. In the test process
that handler also forwards pyln's own machinery logs into the node's
log whenever the test-side logger emits at DEBUG. In particular
wait_for_logs() announces 'Waiting for [pattern]' with the pattern
embedded verbatim, so the announcement lands in the very log being
scanned and matches itself, silently reducing the wait to a no-op.
That let test_sendpay_notifications_nowaiter race its channel close
against the first payment (both payments then fail and the success
assertion sees an empty list); any literal-pattern wait_for_log on an
inline-plugin node is similarly voided under DEBUG logging.

Attach a filter to the inline plugin's log handler that only forwards
records originating outside the pyln packages, so author logging still
reaches the node log but pyln internals never do.

The new test covers both directions: an author log line is found by
wait_for_log, and a never-logged sentinel genuinely times out (it
matched instantly via the forwarded announcement before this fix).

The node directory embeds the test name, and this test's long name
pushes inline-plugin.sock past the AF_UNIX bind cap on some runs:
Linux's 108 bytes under liquid-regtest's longer network dir, and
Darwin's 104 with even the default path. Teach _inline_plugin() to
fall back to binding through a short symlink alias to the socket's
directory -- the same technique UnixSocket.connect already uses on
Darwin, aliasing the directory rather than the socket since bind
can't traverse a dangling final-component symlink. The socket file
still lands where the shim's cwd-relative connect expects it. The
test runs in the macOS smoke set too, so CI exercises the fallback on
the platform with the tighter cap.

Fixes: #9343
Changelog-None
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit fixes a bug in Core Lightning's Python testing toolkit. When tests used an 'inline plugin' and ran with detailed (DEBUG) logging, the test helper wait_for_log() would accidentally see its own 'Waiting for...' message in the node's log and instantly match it, making the wait useless. This caused a real test failure (test_sendpay_notifications_nowaiter) because a payment raced ahead of channel setup. The patch filters out internal pyln log messages from being forwarded into the node log, so only the plugin author's own log lines go through. It also adds a workaround for long Unix socket paths on macOS/Linux so the new test can run. There is no direct security vulnerability here; it is a test-framework correctness fix that closes a small reliability hole in automated tests.

Recommended action

No immediate security action required. This is a testing-framework reliability fix. Reviewers should verify the filter correctly distinguishes pyln internal paths from plugin author paths and that the symlink fallback cleans up its temporary directory on all error paths.

Security signals we found

01

Test-framework self-match bug caused real test race and assertion failure

02

Log forwarding filter prevents internal machinery messages from polluting node logs

03

No privilege escalation, remote attack surface, or cryptographic weakness introduced

04

Fixes publicly referenced issue #9343

Risk score

Why this scored 21/100

Our methodology →
Potential impact 3/30
Exploitability 0/25
Stealth signal 2/15
Affected reach 2/15
Confidence 9/10
Evidence quality 5/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.