[RaviTharuma]

Summary

Secure multimodal /v1/embeddings input for OmniRoute.

• Accepts provider-neutral structured items: text | image | audio | video | document
• URL media is fetched server-side with public-HTTPS checks, redirect revalidation, timeout, size limits, public DNS checks, and connection pinning; providers receive only bounded inline media
• Inline base64 is bounded (8 MiB decoded/item, 16 MiB decoded/request) and rejected before expensive format validation (fixes CI stack overflow)
• Canonical items are translated to provider-native contracts:
  • Jina: modality-keyed {text|image|audio|video|pdf} objects with data URIs; one vector per top-level item
  • Gemini Embedding 2: native models/{model}:embedContent with content.parts
• Unknown/dynamic models without explicit modality metadata reject structured input

Closes #7956

Validation

• node --import tsx/esm --test tests/unit/embeddings-multimodal-7956.test.ts tests/unit/embeddings-handler.test.ts tests/unit/remote-image-fetch.test.ts tests/unit/remote-image-fetch-dns-rebinding.test.ts
• npm run typecheck:core
• npm run check:fabricated-docs

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Code Review

This pull request introduces support for provider-neutral structured multimodal embedding inputs (up to 32 items, including text, image, audio, video, and document modalities) with strict validation limits (8 MiB per inline item, 16 MiB total per request, and safe HTTPS URLs). It updates the OpenAPI schema, API reference documentation, embedding registry, and handler logic to validate and forward these inputs, and adds comprehensive unit tests. The reviewer feedback points out two malformed markdown tables in the API reference documentation where the column counts in the headers do not match their separator lines.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

This markdown table for the MCP Server appears to be malformed. The header defines 3 columns, but the separator line below it defines 4. This can cause rendering issues and makes the table difficult to maintain. Please ensure the number of columns is consistent throughout the table by removing the extra column from the separator and each row.

[gemini-code-assist]

Similar to the table above, this markdown table for "Cloud, Evals & Assess" is malformed. The header has 3 columns, but the separator line has 5. Please correct the table structure for proper rendering and maintainability.

[RaviTharuma]

Rebase note

Rebased onto latest release/v3.8.49 (55549bfe5) to pick up provider/catalog/docs updates.

Local validation on rebased head

• tests/unit/embeddings-multimodal-7956.test.ts — 6/6 pass
• tests/unit/image-generation-handler.test.ts — all pass (DNS pin remains opt-in for embeddings media only)
• npm run typecheck:core — clean

Unrelated base drift still failing on this branch (also present on current release/v3.8.49 tree)

These are not introduced by the multimodal embedding commits; they come from stale catalog/docs expectations vs live counts:

• Docs counts: free-tier headline drift (~1.4B / ~1.37B vs live ~1.53B)
• providers-constants-split: expected 182 APIKEY providers, live 187
• cline-catalog-models-3321: expects minimax/minimax-m3 which is absent from current Cline catalog
• check:fabricated-docs: docs/proxy-subscriptions.md references missing 123_proxy_subscriptions.sql

Happy to leave those for the owning catalog/docs PRs unless maintainers want them fixed here.

[diegosouzapw]

This is a strong piece of security-conscious engineering — the bounded, chunked base64 validator (avoiding both ReDoS and the stack-overflow you mentioned), the reused public-URL SSRF guard, and the modality-allowlist-before-fetch ordering are all solid, and the SSRF rejection tests (private IP / file: / cloud metadata) are exactly what we want to see.

Two things I'd like closed before merge, both in the security surface this PR is hardening:

1. The new createPinnedFetch/pinDns connection-pinning in remoteImageFetch.ts — which closes the DNS-rebinding TOCTOU gap flagged in that file's own prior comment — has no test anywhere (checked the new multimodal test and every existing remote-image-fetch*.test.ts). Could you add one that injects a fake lookup and proves the fetch actually binds to the validated address (similar to the existing DNS-rebinding test file's approach)?

2. The documented '16 MiB decoded per request' cap is enforced by the Zod schema only for base64-sourced items — URL-sourced items are excluded from that aggregate, and since all items are fetched concurrently via Promise.all, a request with 32 URL images (each individually capped at 8 MiB) could pull ~256 MiB into memory at once. Could you fold URL-fetched bytes into the same aggregate check (or otherwise bound total concurrent fetch size) and add a test for it?

Everything else here looks great — happy to take another look once those two are in.