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

pytest: make test_no_delay more robust.

Public commit record

What the developer wrote

Authored by Rusty Russell

78/100 · Adequate
pytest: make test_no_delay more robust.

Unfortunately the effect of leaving Nagle enabled is subtle. Here it
is in v25.12:

Normal:
tests/test_connection.py::test_no_delay PASSED
====================================================================== 1 passed in 13.87s

Nagle enabled:
tests/test_connection.py::test_no_delay PASSED
====================================================================== 1 passed in 21.70s

So it's hard to both catch this issue and not have false positives. Improve the
test by deliberately running with Nagle enabled, so we can do a direct comparison.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit is a test-hardening change. It adds a developer-only flag that lets Core Lightning deliberately keep Nagle's algorithm enabled on TCP sockets, then uses that flag to compare slow vs. fast behavior in an existing test. The production code still disables Nagle by default, so ordinary users are not exposed to any new vulnerability. The change improves the test's ability to detect accidental regressions where Nagle might be left on.

Recommended action

No security response required. Treat as normal test/development tooling improvement. Reviewers may want to confirm the new wire message field is backward-compatible for developer builds.

Security signals we found

01

Adds a developer-only option to intentionally disable a performance optimization (TCP_NODELAY)

02

Modifies a test to detect accidental re-enabling of Nagle's algorithm

03

No change to default runtime behavior; default remains TCP_NODELAY enabled

04

All new flags are gated as developer options (OPT_DEV)

Risk score

Why this scored 18/100

Our methodology →
Potential impact 2/30
Exploitability 0/25
Stealth signal 1/15
Affected reach 2/15
Confidence 9/10
Evidence quality 4/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.