chore(deps)(deps): bump opentelemetry_sdk from 0.28.0 to 0.32.1

[dependabot]

Bumps opentelemetry_sdk from 0.28.0 to 0.32.1.

Changelog

Sourced from opentelemetry_sdk's changelog.

Release Notes 0.32

OpenTelemetry Rust 0.32 continues to drive the Logs, Metrics, and Distributed Tracing components forward. The Logs and Metrics API and SDK remain stable, with no breaking changes in this release. The OTLP Exporters and the Distributed Tracing API/SDK remain in pre-stable states (Release-Candidate and Beta respectively), and this release introduces a small number of intentional breaking changes in those areas to prepare them for stabilization.

For detailed changelogs of individual crates, please refer to their respective changelog files. This document serves as a summary of the main changes.

Key Changes

Metrics SDK

1. Bound instruments (experimental): Added Counter::bind() and Histogram::bind() returning pre-bound measurement handles (BoundCounter<T>, BoundHistogram<T>). Bound instruments resolve the attribute-to-aggregator mapping once at bind time and cache the result, eliminating per-call HashMap lookups on the hot path. Benchmarks show ~28x speedup for counter operations and ~9x for histograms. Gated behind the experimental_metrics_bound_instruments feature flag.

2. Delta collection efficiency: Delta metrics collection now uses in-place eviction instead of draining the HashMap on every collect cycle. Stale attribute sets that received no measurements since the last collection are evicted.

3. Stable Aggregation API: Aggregation and StreamBuilder::with_aggregation() are now stable and no longer require the spec_unstable_metrics_views feature flag.

Logs

1. Tracing-span attribute enrichment (experimental): The opentelemetry-appender-tracing crate can now copy attributes from active tracing spans onto each emitted log record. ("Span" here refers to tracing::span!, not an opentelemetry::trace::Span.) Enrichment is disabled by default with zero per-span overhead, and is gated behind the new experimental_span_attributes cargo feature.

2. spec_unstable_logs_enabled removed: The capability (and the backing specification) is now stable and is enabled by default. The feature flag has been removed.

Distributed Tracing (Beta)

The Distributed Tracing API and SDK remain in beta. This release contains intentional breaking changes to clean up the public surface ahead of

... (truncated)

Commits

• See full diff in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[github-actions]

Auto-approved: all dependency bumps are patch or minor.

[engrams-agent]

Deferring — opentelemetry_sdk cannot be bumped on its own

I picked this up in today's dependency sweep. This one is not a migration at
all: the bump is structurally unlandable as a single-crate PR, and the repo
already has a documented pattern for exactly this shape.

Why it fails

Cargo.toml pins the otel family as a set, with a comment saying so:

# The 0.28 / tracing-opentelemetry 0.29 set is a known-compatible pairing
# and uses tonic 0.12 (matching our gRPC stack).
opentelemetry = "0.28"
opentelemetry_sdk = { version = "0.28", features = ["rt-tokio"] }   # <- only this moved
opentelemetry-otlp = { version = "0.28", features = ["grpc-tonic", "trace"] }
tracing-opentelemetry = "0.29"

opentelemetry-otlp 0.28 requires opentelemetry_sdk ^0.28, so moving only
the sdk resolves two copies of each crate. From this branch's own
Cargo.lock:

opentelemetry       0.28.0   +   opentelemetry       0.32.0
opentelemetry_sdk   0.28.0   +   opentelemetry_sdk   0.32.1

The compiler diagnoses it in exactly those terms. Reproduced against today's
main (cargo check -p engram-telemetry):

error[E0277]: the trait bound `TraceContextPropagator: TextMapPropagator` is not satisfied
note: there are multiple different versions of crate `opentelemetry` in the dependency graph

error[E0599]: no method named `tracer` found for reference `&SdkTracerProvider`
note: there are multiple different versions of crate `opentelemetry` in the dependency graph

error[E0277]: the trait bound `opentelemetry_otlp::SpanExporter:
              opentelemetry_sdk::trace::SpanExporter` is not satisfied
note: there are multiple different versions of crate `opentelemetry_sdk` in the dependency graph

Same trait names, two crate versions, so the impls do not line up. There is
no code change that fixes this — the type error is the honest report that
0.28's otlp exporter and 0.32's sdk are different worlds.

What landing 0.32 actually requires

tracing-opentelemetry version-locks the whole family:

tracing-opentelemetry	requires
0.29 (ours)	opentelemetry, opentelemetry_sdk, opentelemetry-otlp ^0.28
0.33	all of them ^0.32

And the jump reaches past otel into the gRPC stack:

	ours (0.28)	0.32
tonic	^0.12.3	^0.14.1
prost	^0.13	^0.14

So the real unit of work is: opentelemetry + opentelemetry_sdk +
opentelemetry-otlp → 0.32, tracing-opentelemetry → 0.33, and the
tonic/prost stack → 0.14 — which is #1029 (tonic 0.12.3 → 0.14.6), a
substantial migration of its own since tonic 0.14 splits codegen into
tonic-prost.

Worth flagging: #1033 (tracing-opentelemetry 0.29 → 0.33) is the same
bump seen from the other end and fails the same way — its lockfile also
carries opentelemetry 0.28 and 0.32. Neither #446 nor #1033 can go green
alone, and no PR is open for opentelemetry or opentelemetry-otlp at all,
so even landing both together would still leave the family split.

The decision it turns on

Sequencing: tonic 0.14 (#1029) has to land before the otel family can move,
because otlp 0.32 hard-requires it. That makes this a scheduled,
coordinated bump, not a bump-and-fix.

The concrete follow-up I would suggest is a dependabot group, because this
repo already made exactly this call for the same reason —
.github/dependabot.yml says of the grpc group:

the tonic/prost family is version-locked to itself … Individual major PRs
for these crates can NEVER go green — see #25 / #26 / #29 — so "one
crate at a time" is not a reviewable unit here, it is an unbuildable one.

The otel family is that situation verbatim and has no group. Adding
opentelemetry, opentelemetry_sdk, opentelemetry-otlp,
opentelemetry-*, tracing-opentelemetry as a group would make this arrive
as one landable PR instead of two permanently-red ones. I did not make that
config change here: it is a policy edit to dependabot.yml, not this
branch's dependency, and folding it in would break the one-dependency-per-
branch rule.

Why I am NOT adding an ignore

I deliberately did not post @dependabot ignore this major version, even
though this PR will keep reappearing.

An ignore is scoped to the crate and version, not to the PR. Ignoring
opentelemetry_sdk 0.32 would also exclude it from the future grouped otel
PR — that is, it would suppress the crate that the fix depends on and quietly
make the correct bump impossible to assemble. The reappearing PR is noise;
sabotaging the remedy is worse than noise. The grouping change above is the
thing that stops the churn without that side effect.

State of the branch

No source change and nothing pushed. I rebased locally to reproduce against
current main, but the 435-commit-stale Cargo.lock conflicts, and there is
no reason to spend a CI run on a bump that cannot go green — so Dependabot
keeps the branch. The failing lanes above are from June and are still
accurate as to cause.

[engrams-agent]

Deferred — unbuildable alone; the OTel crates are one release set

Triaged in today's sweep. This is not "the migration is hard" — as written, this
PR cannot compile, and neither can its counterpart #1033.

What the failures actually are

fmt + clippy + check, tests (linux), workspace tests (macOS arm64) and
cross-compile linux-musl artifacts all fail together. Four lanes failing as
one set is the signature of a compile error, not a test problem — and it is.

Root cause

The OpenTelemetry Rust crates ship as a single release set. The SDK and exporter
crates depend on an exact opentelemetry core minor. From this PR's own
lockfile:

[[package]]
name = "opentelemetry_sdk"
version = "0.32.1"
dependencies = [
 ...
 "opentelemetry 0.32.0",     <-- requires core 0.32

But the workspace still declares the rest of the family at 0.28
(Cargo.toml:214-217):

opentelemetry = "0.28"
opentelemetry_sdk = { version = "0.32", features = ["rt-tokio"] }   # <- this PR
opentelemetry-otlp = { version = "0.28", features = ["grpc-tonic", "trace"] }
tracing-opentelemetry = "0.29"

So the resolved graph carries both cores at once:

opentelemetry      0.28.0   AND   0.32.0
opentelemetry_sdk  0.28.0   AND   0.32.1

The SDK being configured speaks a different opentelemetry API than the OTLP
exporter and the tracing layer consuming it. Two copies of the same trait
hierarchy do not unify, so the telemetry wiring stops compiling. That is the
whole failure, and no amount of call-site editing fixes it while the other three
crates sit on 0.28.

#1033 (tracing-opentelemetry 0.29 → 0.33) is the mirror image: 0.33 targets
core 0.32, so it is equally unbuildable on its own. The family's skew is
deliberate — tracing-opentelemetry runs one minor ahead of the core it targets
(0.29 → 0.28, 0.33 → 0.32).

Why I did not just fold them together

One dependency per branch. Folding opentelemetry, opentelemetry-otlp and
tracing-opentelemetry into this branch would also discard #1033's own
updated-dependencies: trailer and compatibility score. This repo already has
the right mechanism for a version-locked family — the grpc group for
tonic/prost — and its comment states the principle:

Individual major PRs for these crates can NEVER go green — so "one crate at a
time" is not a reviewable unit here, it is an unbuildable one.

Done this run

#1046 adds an opentelemetry group covering opentelemetry,
opentelemetry-*, opentelemetry_* and tracing-opentelemetry at every update
level, plus the same patterns in cargo-minor-patch's exclude-patterns so
first-match ordering cannot peel one crate back off the set.

Once that lands, Dependabot proposes the whole family as one PR — the first
shape of this upgrade that can be green.

Re-check condition

Superseded, not timed:

1. dependabot: close three config gaps this sweep exposed #1046 merges.
2. Dependabot's next weekly cargo run opens one opentelemetry group PR
   (expected: core 0.32, sdk 0.32, otlp 0.32, tracing-opentelemetry 0.33).
3. That PR gets the migration work — the 0.28 → 0.32 range has real API churn
   in exporter construction and the rt-tokio runtime feature, so it is a
   genuine migration, just a possible one.
4. Close this PR and chore(deps)(deps): bump tracing-opentelemetry from 0.29.0 to 0.33.0 #1033 as superseded once that PR exists — not before.

Also worth knowing

This branch is 441 commits behind main and conflicts on Cargo.lock, so
its red checks are from 2026-06-25 and describe a tree that no longer exists.
Even setting the coupling aside, none of that CI output is current. Not
commenting @dependabot rebase/recreate — both discard pushed work, and a
rebase would not make this buildable.

[engrams-agent]

Closing — superseded by #1060, and the blocker I named in August is gone

Re-checked this in today's sweep, as the earlier deferral required. Both
halves of that deferral have changed, in opposite directions.

The stated blocker no longer exists

The August comment deferred this on "the tonic/prost stack → 0.14 — which is
#1029". That is resolved: #1029 was closed unmerged, but tonic/prost 0.14
landed anyway via #1024 ("deps: tonic/prost family 0.12/0.13 → 0.14 in one
move", merged 2026-08-05, e8bc9c8a). Current main declares tonic,
tonic-prost, tonic-prost-build, tonic-reflection, prost and prost-types all at
0.14.

So the prerequisite is in. otel 0.32 was genuinely unlandable before it — a
clean offline build of the 0.32 set against the old pins fails with
no matching package named 'tonic-types' found ... required by opentelemetry-otlp v0.32.0, and tonic-types only exists on the 0.14 line.

But this PR is still the wrong unit of work

That deferral's other half was right: opentelemetry_sdk cannot move alone.
This PR bumps one crate of a four-crate version-locked set, so its lockfile
carries opentelemetry 0.28.0 and 0.32.0, and the SDK being configured
speaks a different API than the exporter consuming it. No code change fixes
that.

#1060 is that unit — opentelemetry, opentelemetry_sdk,
opentelemetry-otlp → 0.32 and tracing-opentelemetry → 0.33, together, from
the opentelemetry group added in #1046. It contains this PR's exact change
plus the three crates that have to move with it, and its lockfile resolves to
a single coherent set.

It is also a net simplification: main currently carries two tonics
(0.12.3 and 0.14.6), and the only remaining consumers of 0.12.3 are
opentelemetry-otlp 0.28.0 and opentelemetry-proto 0.28.0. #1060 retires
the duplicate.

For the record, #1060 is not blocked on a coupling at all. Its one failure is
a real API migration — tracing-opentelemetry 0.33 made
OpenTelemetrySpanExt::set_parent return a Result, and because ci.yml sets
RUSTFLAGS: -D warnings at workflow scope, that single unused_must_use at
crates/engram-telemetry/src/lib.rs:182 is why all seven Rust lanes go red
rather than one.

Disposition

Closing as superseded. #1033 (tracing-opentelemetry 0.29 → 0.33 alone) — the
mirror-image single-crate PR — was already closed for the same reason, and
this is the last survivor of that pattern. Nothing here is lost; the version
this PR wanted is in #1060.

Follow #1060.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.