[Feat] - Ishaan main merge branch

[ishaan-jaff]

• fix(bedrock): respect s3_region_name for batch file uploads (GovCloud fix)

• fix: s3_region_name always wins over aws_region_name for S3 signing (Greptile feedback)

Relevant issues

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible, it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

CI (LiteLLM team)

CI status guideline:

• 50-55 passing tests: main is stable with minor issues.
• 45-49 passing tests: acceptable but needs attention
• <= 40 passing tests: unstable; be careful with your merges and assess the risk.

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Type

🆕 New Feature
🐛 Bug Fix
🧹 Refactoring
📖 Documentation
🚄 Infrastructure
✅ Test

Changes

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Mar 14, 2026 4:37am

[greptile-apps]

Duplicated s3_region_name extraction logic

The same region resolution block (lines 176-181 and lines 409-413) is duplicated across two methods in the same class. If the priority logic ever needs to change (e.g., adding an AWS_S3_REGION env-var fallback), it must be updated in both places, which is a maintenance hazard.

Consider extracting a small private helper:

def _get_s3_region_name(
    self, litellm_params: dict, optional_params: dict
) -> Optional[str]:
    return litellm_params.get("s3_region_name") or optional_params.get(
        "s3_region_name"
    )

Then both call-sites become a single line:

s3_region_name = self._get_s3_region_name(litellm_params, optional_params)

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

[greptile-apps]

Regex can bypass tag requirements when match_any=True

The strict_tag_check_failed guard only activates when match_any=False. When match_any=True (the default), if a deployment has both tags: ["premium"] and a tag_regex, a request with tags: ["free"] (which fails the tag check) and a matching User-Agent will still be routed to that deployment via the regex path:

• Step 1: is_valid_deployment_tag(["premium"], ["free"], match_any=True) → ∅ → False, falls through
• strict_tag_check_failed = not True and ... = False
• Step 2: regex matches → deployment matched

This may be intentional (both tags and tag_regex act as independent OR conditions), but it creates a surprising asymmetry: in match_any=True mode a "wrong-tagged" request can still hit a deployment just because its User-Agent matches. Operators who configure tags: ["premium"] expecting it to restrict access will find that any client with the right UA bypasses the restriction.

If this is by design, it should be explicitly stated in the documentation (the current docs only note that tag_filtering_match_any=False doesn't apply to regex, not that regex overrides failed tag checks in match_any=True mode).

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ ishaan-jaff
❌ cursoragent
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[greptile-apps]

Tagless requests enter filtering loop when any tag_regex deployment exists

Because the LiteLLM proxy unconditionally writes metadata["user_agent"] from the HTTP User-Agent header for every request (see litellm_pre_call_utils.py:1201), header_strings is almost always non-empty. This means has_tag_filter evaluates to True for every request whenever even one deployment in the pool has tag_regex configured.

For a tagless request (no metadata["tags"]) hitting a mixed pool like:

Deployment A: tags: ["team-a"]        # no tag_regex, no "default"
Deployment B: tag_regex: ["^User-Agent: claude-code\/"]

The filtering loop runs, but:

• Deployment A: _match_deployment → None (step 1 skips because request_tags=None, step 2 skips because no tag_regex)
• Deployment B: _match_deployment → None (regex doesn't match, e.g. Mozilla/5.0)

Result: new_healthy_deployments=[], default_deployments=[] → ValueError raised.

Before this PR, has_tag_filter = bool(request_tags) = False for tagless requests, so all healthy deployments were returned. Adding any tag_regex deployment to an existing pool (without ensuring a tags: ["default"] fallback) is a silent backwards-incompatible change for tagless clients.

Consider adding a safeguard — e.g. fall through to healthy_deployments instead of raising when request_tags is None, or document clearly that a tags: ["default"] deployment is required when using tag_regex.

if len(new_healthy_deployments) == 0 and len(default_deployments) == 0:
    # If the request had no explicit tags, fall through to the unfiltered path
    # rather than raising, to avoid breaking tagless clients when tag_regex
    # deployments are mixed with plain-tag deployments.
    if not request_tags:
        pass  # fall through to the bottom default/all-deployments path
    else:
        raise ValueError(
            f"{RouterErrors.no_deployments_with_tag_routing.value}. Passed model={model} and tags={request_tags}"
        )

[yuneng-jiang]

lgtm