20. Production runtime

Applications own the tracing subscriber. Rent emits structured spans through the tracing crate, so its database activity joins the same request trace as the rest of your service:

use tracing_subscriber::EnvFilter;

tracing_subscriber::fmt()
    .with_env_filter(EnvFilter::new("my_app=info,rent=debug"))
    .try_init()?;

Configure the pool explicitly for production traffic:

use std::time::Duration;

use rent::driver::{DatabasePool, PoolOptions};

let pool = DatabasePool::connect_with(
    dialect,
    &database_url,
    PoolOptions {
        max_connections: 20,
        min_connections: 2,
        acquire_timeout: Duration::from_secs(3),
        idle_timeout: Some(Duration::from_secs(10 * 60)),
        max_lifetime: Some(Duration::from_secs(30 * 60)),
        test_before_acquire: true,
    },
)
.await?;

Parent Rent work with your request span to carry application identifiers without putting sensitive query values into logs:

use rent::tracing::Instrument as _;

let request = rent::tracing::info_span!(
    "publish_post",
    request_id,
    post_id
);

let post = async {
    client
        .post()
        .id_eq(post_id)
        .only()
        .await
}
.instrument(request)
.await?;

Rent records operation names, dialects, statement lengths, bind counts, retry attempts, and transaction boundaries. SQL arguments are deliberately excluded.

The runtime example keeps a minimal model in crates/rent/examples/tutorial_19_runtime/schema.rsl. Run cargo run -p rent --example tutorial_19_runtime. The same runtime configuration runs under nextest.