Rust

e-volv-logs (imported as evolve_logs) is the e-volv Launch SDK for Rust 1.75 and later. It is a server SDK: with a server key (evk_…) it receives the environment’s full ruleset and evaluates flags locally, so a flag check never performs I/O, never blocks and never panics. Delivery is a stream of change notifications (SSE) with a polling fallback, kept fresh by one dedicated std::thread — with or without a Tokio runtime, because the blocking client must never run on a runtime thread — plus a last-known cache on disk and exposure tracking that rides the same init, the same key and the same options as your logs. The behaviour is pinned by the Launch SDK contract and both of its conformance suites run in CI.

Install

cargo add e-volv-logs

The flags module sits behind the default-on cargo feature flags; the default features (tokio, reqwest,flags) give a Tokio-backed batcher and a reqwest transport. default-features = false keeps a plain std::thread path with no async runtime. Flags configure exactly like the e-volv Observer Rust SDK — one Options struct feeds both.

With flags but without reqwest compiled in, the client serves a bundled bootstrap and the on-disk cache only — no HTTP — and says so once on stderr.

Native API

use std::time::Duration;

let layer = evolve_logs::layer(evolve_logs::Options {
    key: "evk_…".into(), // a server key, from the environment
    url: "https://api.e-volv.io/api/public/v1/logs".into(),
    service: "orders-api".into(),
    environment: "production".into(),
    release: "1.4.2".into(),
    ..Default::default()
});
let client = layer.client();
let flags = client.flags();

let context = serde_json::json!({ "targetingKey": "u_1", "plan": "pro" });

// Optional: block (up to the timeout) until the first ruleset
// arrives; the bool reports whether one is held.
let _ = flags.ready(Duration::from_secs(5));

if flags.bool("checkout.new", false, &context) {
    render_new_checkout();
}

// The full answer when you need the variant and the reason:
let d = flags.detail("checkout.banner", serde_json::json!("default"), &context);
// d.value, d.variant (Some("on") / Some("off") / …), d.reason
// ("RULE:0" | "ROLLOUT" | "TARGET_MATCH" | "DEFAULT" | "FLAG_NOT_FOUND" | …)

Evaluation methods: bool, string, number, json and detail, plus typed_detail for the runner protocol — all synchronous, all safe. A flag whose served value is not of the requested type returns your default with reason TYPE_MISMATCH and records no exposure; a flag absent from the ruleset returns your default with FLAG_NOT_FOUND. The context is the same JSON value your logs carry: targetingKey (or key), plus any attributes your rules match on.

Options

Flags are configured on the flags field of the existing Options:

Install check and lifecycle

// Install check: is this key bound, and to which environment?
let ping = flags.verify();
// Some(PingResult { environment: "production", key_kind: "server",
//                     flags: 42, etag: Some("3f2a…".into()) })
// None when the control plane did not answer.

flags.ready(timeout) waits for the first ruleset (only if you choose to), flags.last_updated_at() reports the last confirmed update, flags.mode() reports the delivery mode, and flags.on_change(Box<dyn Fn(&[String]) + Send + Sync>) notifies with the sorted keys whose values changed — drop the returned Subscription to unsubscribe. client.flush() also drains pending exposures, even when telemetry is disabled.

Called from inside a Tokio runtime, the blocking lifecycle calls (verify, flush_exposures, close) move their work onto a short-lived thread, since the blocking HTTP client panics on a runtime thread. Evaluation itself never touches the runtime.

// On shutdown: stop the delivery thread and flush pending exposures.
flags.close(); // idempotent

Dropping the last Client or Guard handle closes flags the same way, so a typical service just lets the guard drop at shutdown.

Troubleshooting by status code

Evaluation never breaks because of the control plane — it degrades. What each response means for the SDK (contract §2.6):

Guarantees

• A flag check is local and synchronous — bounded by CPU, not the network; ready() is the only call that waits, and only when you ask it to.
• An unreachable or slow control plane never changes an answer mid-flag: the last held ruleset (or a valid cache, or your defaults) keeps serving while the delivery thread backs off and reconnects.
• Cold start reads the on-disk cache instantly and swaps to a fresh ruleset without a flicker for unchanged flags; corrupt, oversized or other-environment caches are ignored and overwritten.
• Exposures are de-duplicated, sampled and capped (a 10,000-entry buffer drops oldest first, 1,000 per request) and retried with the same backoff as your logs — telemetry you can trust as much as the flag answers themselves.

The e-volv Launch overview covers concepts and targeting, the HTTP API page documents the wire format the SDK speaks, and the SDKs index lists every platform.