Skip to content

Fix 0.6.2 compatibility test shutdown#947

Merged
tnull merged 1 commit into
lightningdevkit:mainfrom
tnull:2026-06-fix-062-compat-shutdown
Jun 24, 2026
Merged

Fix 0.6.2 compatibility test shutdown#947
tnull merged 1 commit into
lightningdevkit:mainfrom
tnull:2026-06-fix-062-compat-shutdown

Conversation

@tnull

@tnull tnull commented Jun 24, 2026

Copy link
Copy Markdown
Collaborator

Stop and drop the old compatibility node from a blocking region.

This avoids a Tokio runtime-drop panic in the async test.

Honestly not quite sure what changed that this only surfaces now that CI is back (likely an unrelated refactoring while CI was gone is to blame). But we need to fix it so CI finally is green again.

Stop and drop the old compatibility node from a blocking region.

This avoids a Tokio runtime-drop panic in the async test.

Co-Authored-By: HAL 9000
@tnull tnull requested a review from joostjager June 24, 2026 09:00
@ldk-reviews-bot

ldk-reviews-bot commented Jun 24, 2026

Copy link
Copy Markdown

👋 Thanks for assigning @joostjager as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@joostjager

Copy link
Copy Markdown
Contributor

AI analysis regarding why now:

What is happening: v0.6.2's Node::start() creates and stores its own tokio::runtime::Runtime. In the backwards-compatibility test we call node_old.stop() from inside #[tokio::test], so shutdown runs while the test is already executing in a Tokio async context.

The subtle part is the tokio_unstable cfg. In v0.6.2, Node::stop() clones the runtime into metrics_runtime under #[cfg(tokio_unstable)] to log active task metrics. The shutdown body uses block_in_place around its internal runtime.block_on(...) calls, but that extra clone remains alive until the end of stop(). When stop() returns to the async test, the final runtime drop can happen in a context where Tokio does not allow blocking, and Tokio panics with:

Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.


node_old.stop().unwrap();
// Workaround necessary as v0.6.2's runtime wasn't dropsafe in a tokio context.
tokio::task::block_in_place(move || {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The vss_no_auth integration test uses spawn_blocking for a similar code block.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants