hyperhive/swarm-queue-client/Cargo.toml

75 lines
3.6 KiB
TOML

[package]
name = "swarm-queue-client"
version.workspace = true
readme = "README.md"
edition.workspace = true
[features]
# OFF by default, and that default is the point: the auth-callout responder
# consumes this crate for the connect alone and speaks neither `jetstream`
# nor `kv`. A consumer that needs the status bucket says so in its own
# Cargo.toml, so the requirement stays visible where it is incurred.
#
# What is behind the flag is deliberately narrow - the *name and shape* of
# one bucket two crates open from opposite ends (`src/status.rs`), not a
# general "KV support" surface. The crate's job still ends at a connected
# client; the exception exists because an agreement between two crates has
# to live in one of them, and neither end of that bucket is senior to the
# other.
kv = ["async-nats/kv"]
# 🩸 `jetstream` is NOT in async-nats's default feature set here — the
# workspace-level dependency turns default features off entirely (see
# root `Cargo.toml`: `server_2_14`/`nkeys`/`ring` only). `kv` above works
# standalone only because async-nats's own `kv` feature pulls `jetstream`
# in transitively; `notices.rs` uses `async_nats::jetstream` directly and
# needs the same request explicitly, or it only compiles by accident when
# something else in the same build happens to also enable `kv` (which is
# exactly how this went unnoticed: `cargo test` at the workspace level
# unifies features across every crate being built, so `hive-c0re`'s own
# `kv` request silently carried `notices.rs` until a single-crate
# `cargo check -p swarm-nats-auth` — no `kv` anywhere in that build —
# surfaced it as `cannot find jetstream in async_nats`).
notices = ["async-nats/jetstream"]
# OFF by default, same reasoning as `kv`/`notices` above: only a caller
# wiring an OTLP exporter's `HttpClient` seam to this crate's identity
# (today, `swarm-controller`'s `vcs_metrics`/`hive_jobq_metrics`) needs
# `opentelemetry_http`/`async-trait`/`bytes`/`http` pulled in — a plain
# queue-connect-only consumer (the auth-callout responder, a hive
# publishing its status) has no reason to carry them.
otel-auth = [
"dep:opentelemetry-http",
"dep:async-trait",
"dep:bytes",
"dep:http",
]
[dependencies]
# Bare (no `kv`/`jetstream`) unless a consumer opts into the `kv` feature
# above - the connect itself needs none of them.
async-nats.workspace = true
# `blocking` on top of the workspace default (`form`/`json`/`rustls`) —
# `mint_token_for_blocking` needs `reqwest::blocking::Client` for a caller
# with no tokio reactor to `.await` an async request on (an OTLP exporter's
# `HttpClient` impl, see that function's doc). Declared here rather than
# left to arrive transitively from a consumer that happens to pull in
# `reqwest`'s blocking feature some other way — this crate already has a
# recorded case of exactly that kind of accidental compile (see the `kv`
# feature's comment above), and `cargo check -p swarm-queue-client` alone
# must not depend on what else is in the build.
reqwest = { workspace = true, features = ["blocking"] }
# All four `optional = true`, gated behind the `otel-auth` feature above —
# see that feature's own comment for why.
opentelemetry-http = { workspace = true, optional = true }
async-trait = { workspace = true, optional = true }
bytes = { workspace = true, optional = true }
http = { workspace = true, optional = true }
serde.workspace = true
serde_json.workspace = true
# A library, so its errors are a matchable enum rather than an opaque
# `anyhow::Error`. The binaries that consume this keep anyhow; `?` converts.
thiserror.workspace = true
tokio.workspace = true
tracing.workspace = true
[lints]
workspace = true