llamaIndex - 💡(How to fix) Fix CI: integration test matrix in unit_test.yml is red on main, masking signal on downstream PRs [1 pull requests]

Summary

The Unit Testing / test (3.10|3.11|3.12) matrix in .github/workflows/unit_test.yml currently fails on main against ~23 integration packages. This is making it hard for new PRs to demonstrate green CI, since any contribution that runs the full matrix inherits the same failures.

I'm opening this as a tracking issue (not a fix-request) so contributors can reference it and maintainers can prioritize when it makes sense.

Evidence

The narrower workflows — Core Typecheck, CodeQL, Linting, Build Package, Unit Testing / Coverage Check, test-core-py314 — are all green, so the breakage is isolated to the integration matrix.

Failure categories (sample)

Collection errors (ERROR tests/... — missing/changed deps, import errors):

• test_couchbase_search_vector_stores.py
• test_embeddings_huggingface_optimum.py
• test_embeddings_zhipuai.py
• test_extractors_entity.py
• test_llms_zhipuai.py
• test_postprocessor_rankllm-rerank.py
• test_to_weaviate_filter.py
• test_tools_airweave.py
• test_vector_stores_oceanbase.py
• test_vector_stores_weaviate.py

pytest-asyncio config issues (Failed: async def functions are not natively supported):

• test_embeddings_voyageai.py::test_aembed_with_batching
• test_embeddings_voyageai.py::test_async_video_embedding_with_mocked_client
• test_github_app_auth.py::TestGitHubAppAuth::test_get_installation_token_uses_cache
• test_github_app_auth.py::TestGithubClientWithAppAuth::test_get_auth_headers_with_github_app
• test_github_app_auth.py::TestGithubClientWithAppAuth::test_get_auth_headers_with_pat

Async runtime / TaskGroup errors:

• test_tools_mcp.py::test_partial_params_by_tool_removes_fields_for_specific_tool (exceptiongroup.ExceptionGroup: unhandled errors in a TaskGroup on to_tool_list())

Several more packages register as ❌ without surfacing in the test summary — likely pytest exits non-zero before producing a report (e.g. install errors).

Options (no specific ask)

1. Pin/fix the broken packages individually
2. Allow the matrix to continue-on-error per-package while reporting per-package status
3. Move the integration matrix to a scheduled / opt-in workflow so PRs use a smaller required-check set
4. Mark the affected packages as skip in the runner until owners restore them

I'd be happy to send PRs against (2) or (4) if a maintainer signals direction. Mostly opening this so future PR authors don't try (and fail) to fix unrelated packages.

Context

I hit this while rebasing #21228 — happy to drop more diagnostic detail if useful.