AsyncMigrationHarness fails in single thread tokio runtime

[dnaka91]

Setup

Versions

• Rust: 1.90
• Diesel: 2.3.2
• Diesel_async: 0.7.3
• Database: PostgreSQL
• Operating System: Linux

Feature Flags

• diesel: uuid
• diesel_async: async-connection-wrapper, deadpool, migrations, postgres

Problem Description

When using the new AsyncMigrationHarness in an automated test with tokio::test, it panics due to being run in a single-thread runtime by default.

The docs clearly say that the harness using block_in_place and the regular setup uses the multi-threaded runtime anyway. This is more of a nice to have than a bug, because this only happens in test cases and it would be nice to not have to slap the flavor = "multi_thread" on every integration test in the code base.

What are you trying to accomplish?

Trying out the new migration harness helper, as an alternative of running the migrations on tokio's blocking thread pool with spawn_blocking.

What is the expected output?

The helper works regardless of single- or multi-thread runtime.

What is the actual output?

The application panics due to the use of block_in_place, which only works in a multi-thread runtime.

Are you seeing any additional errors?

Steps to reproduce

Checklist

• I have already looked over the issue tracker for similar possible closed issues.

• This issue can be reproduced on Rust's stable channel. (Your issue will be
  closed if this is not the case)
• This issue can be reproduced without requiring a third party crate

[weiznich]

Mind explaining why you believe that this is a bug given that the documentation explicitly states explicitly states that this is the case and you cannot use this harness with the single threaded runtime?

Internally this harness is using tokio::task::block_in_place and AsyncConnectionWrapper to utilize sync Diesel’s migration infrastructure. For most applications this shouldn’t be problematic as migrations are usually run at application startup and most applications default to use the multithreaded tokio runtime. In turn this also means that you cannot use this migration harness if you use the current thread variant of the tokio runtime or if you run migrations in a very special setup (e.g by using tokio::select! or tokio::join! on a future produced by running the migrations). Consider manually construct a blocking task via tokio::task::spawn_blocking instead.

[dnaka91]

My bad, this should have been a feature request rather than a bug. I noticed the ticket type toggle too late.

As mentioned in the description, it'd be a nice to have so we don't have to annotate every integration test to run explicitly on a multi-threaded runtime. After all it saves me maybe one line of code over using spawn_blocking so I'm okay to just keep doing that instead as well.

[weiznich]

I'm not opposed to accept a PR implementing this, but this won't be a priority item for me to work on. So I'm happy to review a PR, but don't expect a implementation from my side.