fix(deps): pin Phoenix auto-trace instrumentors for examples group - #26
Merged
Chang Liu (changliu2) merged 2 commits intoMay 8, 2026
Merged
Conversation
Customers running `examples/phoenix_auto_trace/eval_*.yaml` previously hit a hard crash inside `phoenix.otel.register(auto_instrument=True)` because Phoenix auto-loads every installed `openinference-instrumentation-*` package and a single mismatched version (e.g. instrumentor expects an attribute the framework version we ship does not have) brings down the whole call. Add the four framework-specific instrumentors needed by the phoenix_auto_trace demos to the `[project.optional-dependencies].examples` group with version bounds matched to the framework versions already pinned in the same group: - openinference-instrumentation-openai>=0.1.45 - openinference-instrumentation-litellm>=0.1.30 - openinference-instrumentation-dspy>=0.1.19,<0.1.20 (dspy 2.6.x) - openinference-instrumentation-crewai>=0.1.22,<1.0.0 (crewai 1.6.x) Verified by an 8/8 smoke pass on main (90 transcripts scored across LangGraph, NeurOSan, hosted Azure, and 5 phoenix_auto_trace frameworks) plus Tier 1 unit tests (528 passed). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Chang Liu (changliu2)
added
the
dependencies
Pre-merge audit caught a silent skip: the previous pin
`openinference-instrumentation-crewai>=0.1.22,<1.0.0` resolved to
0.1.22, which requires `crewai>=1.9.0`. Combined with our
`crewai[azure-ai-inference]>=1.6.1` framework pin, this surfaced as
opentelemetry.instrumentation.instrumentor ERROR:
DependencyConflict: requested: `crewai >= 1.9.0` but found: `crewai 1.6.1`
at `register(auto_instrument=True)` time, with the crewai instrumentor
silently disabled. The hard crash this PR fixes was real, but 1 of the 4
pinned instrumentors never actually attached.
PyPI inspection of `openinference-instrumentation-crewai` shows that
0.1.17 is the last release compatible with crewai < 1.9.0 (it requires
`crewai>=0.119.0`, which 1.6.1 satisfies). Tighten the pin to
`>=0.1.17,<0.1.18` so the instrumentor and the framework agree.
Verified locally:
- `register(auto_instrument=True)` -> no DependencyConflict, no crash
- `uv sync --extra examples --extra otel` resolves cleanly
- Unit tests: 528 passed, 14 skipped
Bumping crewai to 1.9.0+ (and the instrumentor to 1.x) is the proper
long-term move; deferred to its own PR so this one stays narrowly
scoped to the auto-instrument crash fix.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
tangym
approved these changes
May 8, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds the four framework-specific OpenInference instrumentors used by
examples/phoenix_auto_trace/eval_*.yamlto theexamplesoptional-dependencies group, with version bounds matched to the framework versions already pinned in the same group.Why
phoenix.otel.register(auto_instrument=True)auto-loads every installedopeninference-instrumentation-*package. A single version-incompatible instrumentor crashes the entire call, breaking unrelated framework demos. Two real failures discovered while smoke-testingmainpost-#21:dspy 2.6.13openinference-instrumentation-dspy 0.1.34(expectsLM.acallnot present)<0.1.20crewai 1.6.1openinference-instrumentation-crewai 1.1.4(requirescrewai>=1.10.1)<1.0.0Plus the
openaiandlitellminstrumentors were not declared at all — customers had to discover them.Pins
toml "openinference-instrumentation-openai>=0.1.45" "openinference-instrumentation-litellm>=0.1.30" "openinference-instrumentation-dspy>=0.1.19,<0.1.20" # dspy 2.6.x "openinference-instrumentation-crewai>=0.1.22,<1.0.0" # crewai 1.6.xA comment in
pyproject.tomlreminds future maintainers to bump these together when bumping crewai >= 1.10 or dspy >= 2.7.Verification
Tier 1 unit tests:
uv run pytest -q-> 528 passed, 14 skipped, 0 failed.Azure smoke test on
main@ 9fa3b30 -> 8/8 configs pass, 90 transcripts scored end-to-end through the SvelteKit viewer:Viewer (
npm run devinviewer/) renders all 4 suites;framework-eval-minicorrectly groups all 5 framework runs; every run-detail page returns HTTP 200 with ~1.4MB of hydrated transcripts and scores.Notes (not addressed in this PR)
litellmandcrewaioutliers above were Azure throttling +RemoteDisconnectedretries, not code bugs (the rate-limit retry code from feat: coordinated rate-limit retry with per-model adaptive backoff #17 worked, just slowly).openinference-instrumentation-crewai 0.1.22still emits a non-fatalDependencyConflict: requested 'crewai >= 1.9.0' but found 'crewai 1.6.1'warning at register time. Harmless but worth bumping crewai in a follow-up.