Skip to content

feat(retrievers): add Microsoft Web IQ support - #2015

Open
sxwxs wants to merge 1 commit into
assafelovic:mainfrom
sxwxs:feat/webiq-retriever
Open

feat(retrievers): add Microsoft Web IQ support#2015
sxwxs wants to merge 1 commit into
assafelovic:mainfrom
sxwxs:feat/webiq-retriever

Conversation

@sxwxs

@sxwxs sxwxs commented Jul 30, 2026

Copy link
Copy Markdown

Add an opt-in Web IQ Web Search v3 retriever with per-request API key injection, domain filtering, configuration documentation, malformed-response guards, and mocked unit tests.

Follow the official document: https://webiq.microsoft.ai/documentation/ and tested using real API.

    Add an opt-in Web IQ Web Search v3 retriever with per-request API key injection, domain filtering, configuration documentation, malformed-response guar
ds, and mocked unit tests.
@assafelovic

Copy link
Copy Markdown
Owner

Reviewed — this is the most thorough of the retriever PRs (10 files, tests, docs, .env.example, config reference, and the most error handling of the set). It no longer applies to main after #2074 and needs a rebase.

One thing worth confirming in the description when you rebase: the endpoint is https://api.microsoft.ai. Since the PR is titled Microsoft Web IQ, it would help to state plainly whether this is an official Microsoft service and where its docs live — a first-party API is a different maintenance proposition from a third-party one.


Why this is not merged yet, and it isn't code quality.

main already ships 22 retrievers. Six open PRs (#1814, #1850, #1867, #2015, #2048, #2068) would add seven more, and most come from the vendor whose API is being added. Each one is a few hundred lines the project maintains indefinitely, behind an API key CI cannot hold, against a service whose uptime and response shape nobody here controls — and the recently-merged work included roughly twenty separate fixes for retrievers returning payload shapes their parsers did not expect.

That is a scope decision for @assafelovic, not a verdict on this patch. The sustainable answer is probably a documented plugin path — an entry-point group so a vendor ships and versions their own package — rather than accepting or rejecting each of these case by case, which is exactly why they have all been sitting.

Not closing it. Flagging it so the decision gets made once instead of six times.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs-maintainer-decision Blocked on a call only the maintainer can make

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants