Many imorovments

ui/dr-ui/src/net_runtime.rs

@@ -0,0 +1,34 @@
+//! The tokio runtime every network worker is built from.
+//!
+//! One function rather than a builder repeated at each call site, because the
+//! choice it encodes is not obvious and was wrong in eleven places at once.
+//!
+//! **Why not `new_current_thread`.** A current-thread runtime drives its
+//! reactor only while the thread is inside `block_on`. On Android that left
+//! reqwest's connection future unpolled: the await never resolved, so the
+//! worker neither failed nor returned. Every symptom was an absence — no error,
+//! no panic for `catch_unwind` to catch, no log line, and a channel that closed
+//! only when the thread was finally torn down. What the user saw was a sign-in
+//! that stopped, and a library that quietly scanned itself rather than adopting
+//! the shards the server already held.
+//!
+//! A multi-thread runtime owns worker threads that poll the reactor regardless.
+//! One worker is enough: these are single request-response flows, not
+//! throughput-bound work.
+//!
+//! **Why not `enable_all`.** That also starts the signal driver, which wants
+//! process-wide signal handling. Inside an Android app the runtime already owns
+//! that, and a worker thread claiming it is asking for trouble. These flows need
+//! IO (reqwest) and time (poll intervals, timeouts) and nothing else.
+
+/// Build a runtime suitable for a network worker thread.
+///
+/// Call from the spawned thread, not from the caller: the runtime must live on
+/// the thread that blocks on it.
+pub fn build() -> std::io::Result<tokio::runtime::Runtime> {
+    tokio::runtime::Builder::new_multi_thread()
+        .worker_threads(1)
+        .enable_io()
+        .enable_time()
+        .build()
+}