Remote Replica Initialization Fails in Tauri Environment due to Thread-Local Tokio State

When using libsql v0.4.0’s remote replication feature within a Tauri application, the initialization fails with the following panic:

thread '...' panicked at ...\libsql-0.4.0\src\local\database.rs:209:17:
assertion `left == right` failed: libsql was configured with an incorrect threading configuration and
the API is not safe to use. Please check that no multi-thread options have been set.
  left: 21
  right: 0

I’m attempting to isolate remote replica initialization in a dedicated thread so that no Tokio runtime state interferes. I tried two approaches:

1. Using Tokio’s new_current_thread() runtime on a dedicated thread.
2. Switching to futures::executor::block_on in that dedicated thread.

In both cases, libsql still detects a nonzero thread-local counter (21 instead of 0) and panics. This suggests that even our “dedicated” thread inherits contamination from the global runtime environment used by Tauri.

Steps to Reproduce

1. Create a Tauri application that uses libsql v0.4.0 with the remote replication feature enabled.
2. In the app, attempt to initialize the remote replica by calling new_remote_replica() from a dedicated thread.
3. In that dedicated thread, use either:
   • a Tokio single-threaded runtime (e.g. via tokio::runtime::Builder::new_current_thread().build()) or
   • a synchronous executor (e.g. futures::executor::block_on) to run the asynchronous initialization.
4. The initialization panics with the thread-local assertion error.

Expected Behavior

The remote replica should initialize successfully when isolated in a dedicated thread that does not contain any asynchronous runtime state. Ideally, the thread-local counter should be zero.

Actual Behavior

Even when using a dedicated thread and switching to a synchronous executor (futures::executor::block_on), libsql panics because it detects a nonzero thread-local counter (21) instead of the expected 0.

Environment Details

• libsql version: 0.4.0
• Tauri version: 2.3.1
• Tokio version: 1.44.0
• Operating System: Windows 11
• Additional Context:
  • The application uses Tauri, which employs a multi-threaded Tokio runtime globally.
  • I need remote replica operations to run on a “clean” thread without any contamination from Tauri’s runtime.

Workarounds Attempted

• Dedicated Thread with Tokio Runtime:
  Spawned a dedicated thread with a single-threaded Tokio runtime. However, this still left a nonzero thread-local counter (21).
• Synchronous Executor:
  Replaced the Tokio runtime with futures::executor::block_on in the dedicated thread, but the issue persists.
• Separate Process:
  Running the remote replica in a separate process works as a workaround, but it isn’t ideal for the use case.

Questions

• Is there a recommended method to initialize libsql’s remote replica in an environment like Tauri where a global multi-threaded runtime is active without encountering this thread-local contamination?
• Can libsql offer a synchronous API for remote replication initialization or a configuration option to disable the thread-local runtime check?
• Are there any known workarounds for this issue when using libsql within Tauri?

Thanks for your assistance!

Start with libsql-0.4.0/src/local/database.rs at the assertion around line 209 and trace the new_remote_replica() initialization path described in the report. Reproduce it in the stated Tauri, Windows, and libsql versions using both dedicated-thread approaches, then determine whether a supported initialization method or configuration change avoids the panic.