chore(release): backport #32256, #32405, #32524 to stable/1.91.x and cut 1.91.1

[yuneng-berri]

Relevant issues

Backports three merged fixes from litellm_internal_staging onto stable/1.91.x and cuts 1.91.1.

The first two restore consistent os.environ/ reference resolution for DB-sourced models, matching what the YAML config path has always done. On 1.91.0 a model stored in the DB with an env-ref auth field (for example aws_role_name: os.environ/BEDROCK_ASSUME_ROLE_ARN) reached the provider as the literal string instead of the resolved value, because an earlier change (#30867, present on this line) stopped expanding those references at request time and the DB-load path only re-expanded a short hardcoded allowlist. #32256 extends that allowlist to cover every AWS auth field; #32405 then removes the allowlist and the team-scope short-circuit entirely so the DB-load resolver expands os.environ/ on every string field, which is the same behavior as the YAML path and removes the recurring "add one more field to the allowlist" failure mode.

The third restores v1-parity error detail on OpenTelemetry v2 failure spans (#32524, LIT-4179) so backends that index span attributes see the full error shape again, not only error.type.

Linear ticket

Pre-Submission checklist

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review

What is included

Cherry-picked from staging in merge order, each with a cherry picked from commit footer:

• fix(proxy): resolve os.environ/ refs for all AWS auth params in DB-sourced models #32256 fix(proxy): resolve os.environ/ refs for all AWS auth params in DB-sourced models (staging 7d13f03f)
• fix(proxy): resolve os.environ/ refs universally in DB-sourced models #32405 fix(proxy): resolve os.environ/ refs universally in DB-sourced models (staging ec4f3244)
• fix(otel): restore error.* span attributes on v2 error spans (LIT-4179) #32524 fix(otel): restore error.* span attributes on v2 error spans (staging 85d1fe6e2a)

Followed by the version bump to 1.91.1 and the uv.lock refresh. 1.91.0 has already shipped, so the line needs a new patch.

Behavior note worth calling out for reviewers: #32405 removes the _db_model_is_team_scoped short-circuit, so after this change team-scoped DB models resolve os.environ/ references the same way admin-scoped rows do. That is intentional and matches the staging change; the write side stays gated (only an admin can author unscoped rows, only a team admin can author that team's rows) and the request-body vector remains blocked by _BANNED_REQUEST_BODY_PARAMS.

Adaptation notes

• fix(proxy): resolve os.environ/ refs for all AWS auth params in DB-sourced models #32256 applied verbatim (patch-id identical to the staging commit).
• fix(proxy): resolve os.environ/ refs for all AWS auth params in DB-sourced models #32256 and fix(proxy): resolve os.environ/ refs universally in DB-sourced models #32405 merged on staging as merge commits, so each was picked with -m 1 against its merge SHA; the resulting stable commits carry the staging merge subject and the merge author. The applied code is byte-for-byte identical to the staging change.
• fix(proxy): resolve os.environ/ refs universally in DB-sourced models #32405 and fix(otel): restore error.* span attributes on v2 error spans (LIT-4179) #32524 show as "adapted" only because surrounding context lines differ slightly on this older tree; the added and removed lines themselves are byte-for-byte identical to the staging commits (verified line-by-line per file). No logic diverges.

Known noise on this line

None. The targeted baseline (the three test files these PRs touch) was fully green on the bare line tip before any pick: 166 passed, 0 failures. After the picks it is 174 passed, 0 failures (the delta is the new regression tests the picks add).

Screenshots / Proof of Fix

Live proxy on this branch, backed by a real Postgres with store_model_in_db: true. Model rows are created through /model/new (so they travel the DB-load path this change touches) and read back through /v2/model/info.

Admin-scoped model, aws_role_name set to an env-ref, resolves to the real value:

$ export FOO_ARBITRARY="admin-arbitrary-resolved"
$ curl -sS -X POST http://localhost:4011/model/new -H "Authorization: Bearer sk-1234" -H "Content-Type: application/json" \
    -d '{"model_name":"repro-admin","litellm_params":{"model":"openai/gpt-4o-mini","api_key":"sk-fake-not-used","aws_role_name":"os.environ/FOO_ARBITRARY"}}'

$ curl -sS "http://localhost:4011/v2/model/info" -H "Authorization: Bearer sk-1234" | jq -c '.data[] | select(.model_name=="repro-admin") | {model_name, aws_role_name: .litellm_params.aws_role_name}'
{"model_name":"repro-admin","aws_role_name":"admin-arbitrary-resolved"}

Arbitrary non-allowlisted field resolves too, which is the point of dropping the allowlist:

$ curl -sS -X POST http://localhost:4011/model/new -H "Authorization: Bearer sk-1234" -H "Content-Type: application/json" \
    -d '{"model_name":"repro-arbitrary","litellm_params":{"model":"openai/gpt-4o-mini","api_key":"sk-fake-not-used","some_future_field":"os.environ/FOO_ARBITRARY"}}'

$ curl -sS "http://localhost:4011/v2/model/info" -H "Authorization: Bearer sk-1234" | jq -c '.data[] | select(.model_name=="repro-arbitrary") | {model_name, some_future_field: .litellm_params.some_future_field}'
{"model_name":"repro-arbitrary","some_future_field":"admin-arbitrary-resolved"}

Negative control, the request-body vector stays blocked:

$ curl -sS -o /dev/null -w "HTTP=%{http_code}\n" -X POST http://localhost:4011/v1/chat/completions -H "Authorization: Bearer sk-1234" -H "Content-Type: application/json" \
    -d '{"model":"repro-admin","messages":[{"role":"user","content":"hi"}],"aws_role_name":"os.environ/DATABASE_URL"}'
HTTP=401

The team-scoped resolution path (/model/new with a team_id) is Enterprise-gated at write time, so it is not shown here as a live curl; it is covered by the unit test test_ProxyConfig__add_deployment_resolves_team_env_refs, and mechanically it now follows the exact same resolver shown above once the team-scope short-circuit is removed.

#32524 is additive observability behavior on OTel v2 failure spans; it is covered by the extended tests under tests/test_litellm/integrations/otel/ (including a byte-for-byte v1 attribute-key parity test and a per-field guard), which pass on this branch. The staging PR carries the Jaeger before/after capture.

Targeted test delta on this branch: 174 passed, 0 failures (baseline 166 passed, 0 failures). A deep multi-agent behavioral stress-test (confirm and refute lenses plus an audit pass) returned SURVIVED on all three sub-claims (every referenced symbol resolves; the picks' own tests pass as a positive delta over the clean baseline; no existing caller of the modified functions breaks) with zero verified findings.

Type

🐛 Bug Fix

Changes

litellm/proxy/proxy_server.py: DB-load env-ref resolution no longer gates on a key allowlist or on team-scope; ProxyConfig._resolve_db_litellm_param expands any string value beginning with os.environ/. The _DB_LITELLM_PARAM_ENV_REF_KEYS allowlist and the _db_model_is_team_scoped helper are removed.

litellm/integrations/otel/: the v2 emitter stamps error.code, error.stack_trace, error.llm_provider, and error.message in addition to error.type on failure spans, with keys matching the v1 integration; the detail keys are stamped per field so message-only errors are not padded with empty attributes.