test(e2e): clear the two rc/1.103.0 e2e reds owned by upstream providers

[yuneng-berri]

TLDR

Problem this solves:

• litellm-e2e build 308 on rc/1.103.0 went red on two things outside LiteLLM's control
• Azure took over 660s to cancel a batch, so test_batch_lifecycle[azure-unified] errored in teardown
• DeepWiki renamed its ask_question tool to ask_wiki_question, so the MCP Tools UI test failed

How it solves it:

• Backports the batch cleanup part of test(e2e): assert only litellm-owned batch behavior and move the blank S3 env pin to an integration test #43321: a batch still cancelling after 120s, and the file it holds, become warnings instead of errors
• Any other cleanup status or error still fails, and Azure's cancel response is now asserted
• Points the MCP Tools UI test at ask_wiki_question
• Test files only

Relevant issues

Partial backport of #43321

Pre-Submission checklist

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

• I have added meaningful tests
• The handful of test files covering my change pass locally, e.g. uv run pytest tests/test_litellm/<your_test_file>.py -v. Leave the suites (make test-unit-*, make test-unit) to CI: it finishes in ~15 minutes where a laptop takes an hour or more
• My PR passes all required CI/CD checks (e.g., lint, schema.d.ts sync check, etc.)
• 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 (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

tests/e2e/batches/test_batch_cleanup.py passes on this branch (50 tests). DeepWiki's live tools/list returns ask_wiki_question, read_wiki_contents and read_wiki_structure

Adaptations from #43321: rc/1.103.0 never had the blank S3 env e2e test, so its removal, the integration test that replaces it, and the coverage registry edits are left out. batch_cleanup.py and test_batch_cleanup.py are taken from main as of #43321, which also carries a one-line message assertion from #43294

Type

✅ Test

Caveats (if any)

Low

• The DeepWiki fix still names upstream tools; main checks against DeepWiki's live tool list instead (test(e2e-ui): check the MCP Tools tab against the upstream's own tools/list #42397), which needs a new e2e UI dependency
• The Mistral OCR 429 in the same build is a provider rate limit and is not addressed here
• The two secret manager lanes are fixed separately in project-releaser, since the lane script lives there

[greptile-apps]

Confidence Score: 4/5

[Low risk] Adjusts end-to-end test timeouts and error handling.

The PR should not merge while the Azure lifecycle test newly asserts calls previously excluded for provider-side flakiness.

Findings

1.  Azure cancellation flakes return ▶

Summary

The PR shortens batch cancellation cleanup waits, reports still-cancelling batches and blocked file deletions as warnings, and updates the DeepWiki UI tool expectation. It also begins asserting Azure cancellation in the lifecycle test, which re-exposes the test to previously documented provider-call flakes.

_{Reviews (1) · Last reviewed commit: "test(e2e): clear the two rc/1.103.0 e2e ..."}

[greptile-apps]

Azure cancellation flakes return Adding Azure to this set makes every Azure lifecycle case retrieve and cancel the batch during the test. Azure was previously excluded because these provider calls can fail intermittently. If the connection is refused, the helpers do not retry it, so the test fails even when batch creation and retrieval worked and cleanup could proceed.