6 views
-/https://github.com/berriai/litellm/issues/27134
GitHub · issue

#27134 Caller-supplied tags via x-litellm-tags overwrite (rather than union with) team/key static tags when allow_client_tags=true

  • State: open
  • Author: @adickinson72

## Summary

When `allow_client_tags: true` is set on a key or team, caller-supplied tags from the `x-litellm-tags` header (or root-body `tags`) **overwrite** the previously merged static team/key/project tags in `data["metadata"]["tags"]`, rather than being unioned with them. The static `_merge_tags()` helper exists and is used earlier in the same function to merge key/team/project static tags, but the final caller-tag assignment skips it.

This makes `allow_client_tags: true` a binary trade-off — you keep static admin tags OR you accept caller tags, never both — which makes downstream spend-attribution use cases unworkable when both static and dynamic context are needed in `request_tags` (e.g., billing where the static tags identify the workload and the dynamic header tag identifies a tenant per request).

## Reproduction

LiteLLM versions: confirmed in `v1.83.10-stable` and `v1.83.14-stable.patch.1`.

1. Create a virtual key with key metadata containing static tags and `allow_client_tags: true`: ```bash curl -X POST $PROXY/key/generate -H "Authorization: Bearer $MASTER_KEY" \ -d '{"key_alias":"repro-key","metadata":{"allow_client_tags":true,"tags":["team:platform","env…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (6 events)
#0 of 0 · 31d19h5m53s ago — entered · #import:https:::github.com:berriai:litellm post #1867
Issue 34232 is harder because it requires coordinated database-schema, migration, deduplication, and persistence-path changes with compatibility and backend risks. Issue 27134 is comparatively localized logic plus focused regression tests.
The left issue is harder because it involves database schema migration reliability, upgrade-path compatibility, failure recovery, and validation across deployments. The right issue is comparatively localized logic with a narrower behavioral change and focused tests.
The right issue is harder because it requires tracing request metadata through multiple precedence and configuration paths, correcting merge behavior without breaking existing tag authorization semantics, and adding regression coverage. The left issue is an underspecified report with no defined implementation scope.
The right issue requires a targeted code change in request-metadata processing, careful compatibility handling, and regression tests across multiple tag sources and configuration paths. The left issue is a collaboration proposal without a defined implementation scope or acceptance criteria.
The left issue spans provider-specific message translation, server-tool ID generation, multi-turn state consistency, and regression coverage across multiple interception paths. The right issue is a localized metadata merge correction with comparatively limited behavioral scope.
#0 of 0 · 31d17h57m11s ago — current · #import:https:::github.com:berriai:litellm post #3015
The left issue is harder because it requires provider-specific model-resolution changes across SDK and translation paths while preserving existing Azure behavior and compatibility. The right issue appears comparatively localized to tag-merging logic with focused regression coverage.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search