Show which LLM providers each Common AI connection type reaches - #70497
Merged
Conversation
boring-cyborg
Bot
added
area:dev-tools
area:providers
area:registry
backport-to-v3-3-test
Lee-W
force-pushed
the
registry-llm-connection-matrix
branch
from
July 28, 2026 15:10
9ba6927 to
a96a2d8
Compare
Lee-W
marked this pull request as ready for review
July 28, 2026 15:12
Lee-W
requested review from
amoghrajesh,
ashb,
bugraoz93,
choo121600,
ephraimbuddy,
gopidesupavan,
jason810496,
jedcunningham,
jscheffl,
kaxil,
potiuk and
vatsrahul1001
as code owners
July 28, 2026 15:13
Lee-W
force-pushed
the
registry-llm-connection-matrix
branch
3 times, most recently
from
July 31, 2026 04:56
033ea83 to
3808b0a
Compare
kaxil
reviewed
Jul 31, 2026
Lee-W
force-pushed
the
registry-llm-connection-matrix
branch
from
August 3, 2026 00:38
3808b0a to
3544dd4
Compare
kaxil
approved these changes
Aug 3, 2026
Lee-W
force-pushed
the
registry-llm-connection-matrix
branch
2 times, most recently
from
August 5, 2026 03:41
ecdbe47 to
fed575f
Compare
Lee-W
force-pushed
the
registry-llm-connection-matrix
branch
6 times, most recently
from
August 6, 2026 08:19
4769100 to
551f921
Compare
Registry visitors browsing the Common AI provider page could see chips for pydanticai, pydanticai-azure, pydanticai-bedrock, langchain, etc. but had no way to tell which upstream service (Anthropic, AWS Bedrock, Ollama, ...) each one actually talks to without reading source code. Add an optional external-integrations list to the connection-types schema and populate it in the Common AI provider.yaml from the existing connection docs, thread it through the registry metadata extractor and contract model, and render it as a small badge list under each connection chip on the provider detail page.
Cramming a variable-length badge list under each connection-type chip (one connection type has 9 upstream providers, others have just 1) produced uneven, hard-to-scan rows in the chip strip. Keep the chip row uniform and move the upstream-provider data into its own compact table below it.
Rows with many upstream providers (pydanticai has 9) made the table feel noisy even after moving badges out of the chip row. Collapse any row with more than 4 providers behind a "Show N providers" toggle, reusing the same details/summary show/hide pattern already used for the Dependencies list on this page. Short rows stay as plain badges.
This reverts commit 216a27f.
The badge-pill styling and its show/hide toggle added a second interaction pattern on top of the existing clickable chip row, making the section feel fussy. Render each row's upstream providers as a plain comma-separated list instead -- still fully visible at a glance, no extra affordance, and visually lighter than bordered pills.
The previous name sat one key away from provider.yaml's top-level integrations, which describes a different axis entirely -- framework integrations that drive docs pages, logos and tags -- so provider authors skimming the schema could easily conflate the two. The field also had no entry in the one document where authors learn what connection-types sub-fields exist, leaving it undiscoverable.
The LlamaIndex entry advertised vendors the connection cannot actually reach: the hook only ever builds llama-index's OpenAI classes, and the vendors it documents as needing direct instantiation bypass the hook and the connection entirely. Mistral was also spelled two different ways across entries that render in the same table, reading as two separate upstreams, and DeepSeek was absent even though the Pydantic AI hook covers it.
The registry version page reads connection types from a different source for superseded releases than for the latest one, so a field only present in the latest-release extractor makes the table visible while a release is current and then silently disappear once a newer one ships.
The field had no coverage at all, so removing the line that reads it out of provider.yaml would not have failed anything. Driving both extractors through the connection contract, which forbids extra keys, also ties the YAML key, the extracted JSON key and the contract field name together so a rename in one of them can no longer drift silently past CI.
The three generic AI connection types applied three different rules to OpenAI-compatible self-hosted endpoints, so the registry table read as if the langchain connection could not reach vLLM. Every one of these hooks passes conn.host straight through as base_url, and none of their docstrings name LM Studio, so the lists now follow what the hooks actually document as reachable.
The registry rendered a bare "External services" column, so a reader takes the list as the complete set. The generic AI connection types resolve their destination from a caller-supplied model identifier, so they reach whatever service that identifier names: an enumeration can never be complete, and it would need an edit every time an upstream library adds a provider. Saying so where readers meet the field keeps a partial list from reading as a compatibility matrix.
The provider.yaml field settled on external-services, but the table's CSS classes and comment still carried the earlier "integrations" name. Nothing consumes them yet, so renaming now costs nothing and avoids leaving a name in the stylesheet that no longer matches anything readers can look up.
Lee-W
force-pushed
the
registry-llm-connection-matrix
branch
from
August 6, 2026 08:32
551f921 to
07fa2b9
Compare
Contributor
Backport failed to create: v3-3-test. View the failure log Run detailsNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
You can attempt to backport this manually by running: cherry_picker 43384c7 v3-3-testThis should apply the commit to the v3-3-test branch and leave the commit in conflict state marking After you have resolved the conflicts, you can continue the backport process by running: cherry_picker --continueIf you don't have cherry-picker installed, see the installation guide. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Common AI provider page shows
pydanticai, pydanticai-azure, pydanticai-bedrock, langchain, etc. but not upstream service (Anthropic, AWS Bedrock, Ollama, ...) each one actually talks to without reading source code.What
Add an optional external-integrations list to the connection-types schema and populate it in the Common AI provider.yaml from the existing connection docs, thread it through the registry metadata extractor and contract model, and render it as a small badge list under each connection chip on the provider detail page.
Was generative AI tooling used to co-author this PR?
Generated-by: [Claude] following the guidelines
{pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.