Skip to content

fix(microsoft-foundry): filter Anthropic deployments during onboard#72446

Open
ottodeng wants to merge 5 commits intoopenclaw:mainfrom
ottodeng:fix/foundry-filter-anthropic-deployments
Open

fix(microsoft-foundry): filter Anthropic deployments during onboard#72446
ottodeng wants to merge 5 commits intoopenclaw:mainfrom
ottodeng:fix/foundry-filter-anthropic-deployments

Conversation

@ottodeng
Copy link
Copy Markdown
Contributor

@ottodeng ottodeng commented Apr 27, 2026

Summary

The built-in microsoft-foundry provider only supports OpenAI-compatible Foundry APIs (chat/completions, responses). However, Anthropic (Claude) deployments on Azure AI Foundry use a different API shape (/anthropic/v1/messages) that is not wired yet. This causes silent 404 failures at runtime after apparently successful onboarding — the user selects a Claude deployment, configuration looks correct, but requests fail.

Changes

  • Add isAnthropicFoundryDeployment() to detect Claude model names
  • Filter Anthropic deployments from the selection list during onboard
  • Show an informative note with workaround (custom provider with anthropic-messages API) when Anthropic deployments are skipped
  • Provide a specific error message when only Anthropic deployments exist in the resource
  • Add tests for the detection function (11 test cases)

Why Option B (guardrail)

The issue suggests two approaches: full Anthropic API support (Option A) or a guardrail (Option B). This PR implements Option B because:

  • It prevents the confusing "config succeeded but runtime fails" experience immediately
  • The workaround (custom provider) is clearly communicated to users
  • Full Anthropic Foundry support can be added later without breaking this guardrail

Testing

  • 36 tests pass (vitest run extensions/microsoft-foundry/index.test.ts)
  • New tests cover: Claude model name detection (4 variants), non-Anthropic rejection (7 variants including edge cases)

Fixes #60546

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented Apr 27, 2026

Greptile Summary

This PR adds a guardrail to the microsoft-foundry onboarding flow that filters out Anthropic (Claude) deployments, which use a different API shape (/anthropic/v1/messages) not supported by the built-in provider. When such deployments are detected, an informative note is shown with a custom-provider workaround, and a clear error is thrown if no OpenAI-compatible deployments remain.

Confidence Score: 5/5

Safe to merge — the change is self-contained, well-tested, and prevents a silent runtime failure without breaking existing functionality.

Logic is sound: normalizeFoundryModelName lowercases before the startsWith('claude') check handles all case variants, null/undefined/empty are handled gracefully, and the filtering correctly uses modelName (the actual model) rather than the deployment name. Tests cover all relevant edge cases. No existing behavior is removed.

No files require special attention.

Reviews (1): Last reviewed commit: "fix(microsoft-foundry): filter Anthropic..." | Re-trigger Greptile

@clawsweeper
Copy link
Copy Markdown
Contributor

clawsweeper Bot commented Apr 27, 2026 •
edited
Loading

Codex review: needs real behavior proof before merge.

Summary
The branch filters Claude/Anthropic Microsoft Foundry deployments from onboarding and persisted deployment catalogs, adds warning/error copy and regression tests, and updates the changelog.

Reproducibility: yes. for source-level reproduction: current main offers and persists all succeeded Foundry deployments while runtime/base URL construction only targets /openai/v1. I did not run a live Azure Foundry account.

Real behavior proof
Needs real behavior proof before merge: Needs real behavior proof before merge: current evidence is only tests/local checks, so the contributor should add redacted Azure Foundry onboarding output, logs, screenshot, or recording to the PR body; that should trigger ClawSweeper re-review, or a maintainer can comment @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, ask a maintainer to comment @clawsweeper re-review.

Next step before merge
Human/contributor action remains: resolve committed changelog conflict markers and provide redacted real Azure Foundry onboarding proof; automation cannot supply the contributor's Azure account proof.

Security
Cleared: Cleared: the diff only changes provider-local onboarding/filtering, tests, and changelog text and adds no dependencies, workflows, artifact downloads, or secret-handling changes.

Review findings

  • [P2] Resolve the CHANGELOG merge markers — CHANGELOG.md:156-158
Review details

Best possible solution:

Resolve the changelog markers, add redacted live Azure Foundry onboarding proof, then land the provider-local guardrail once exact-head checks are green.

Do we have a high-confidence way to reproduce the issue?

Yes for source-level reproduction: current main offers and persists all succeeded Foundry deployments while runtime/base URL construction only targets /openai/v1. I did not run a live Azure Foundry account.

Is this the best way to solve the issue?

Yes for the immediate bug once cleaned up: a provider-local guardrail is narrower than implementing full Anthropic Foundry support here, while #47181 remains the separate first-class Azure Claude onboarding effort.

Full review comments:

  • [P2] Resolve the CHANGELOG merge markers — CHANGELOG.md:156-158
    The current head contains literal conflict markers in CHANGELOG.md, so merging this would leave invalid release notes in the tree. Please resolve the changelog conflict and keep both intended entries without the marker lines.
    Confidence: 0.99

Overall correctness: patch is incorrect
Overall confidence: 0.93

What I checked:

Likely related people:

  • haxudev: Introduced the Microsoft Foundry provider, including discovery, onboarding selection, persisted deployment catalog generation, and OpenAI-compatible routing. (role: introduced behavior; confidence: high; commits: a16dd967da51; files: extensions/microsoft-foundry/auth.ts, extensions/microsoft-foundry/onboard.ts, extensions/microsoft-foundry/shared.ts)
  • steipete: Recent main-branch work repeatedly touched Microsoft Foundry onboarding, shared provider helpers, and tests around this path. (role: recent maintainer; confidence: high; commits: 05f607c149ce, cc470dbfc1ec, c0dc3b3cb72d; files: extensions/microsoft-foundry/onboard.ts, extensions/microsoft-foundry/shared.ts, extensions/microsoft-foundry/index.test.ts)
  • Takhoffman: Recent Foundry model capability work changed shared provider behavior and tests near deployment metadata and runtime normalization. (role: adjacent maintainer; confidence: medium; commits: d28b02a7b131; files: extensions/microsoft-foundry/shared.ts, extensions/microsoft-foundry/index.test.ts, extensions/microsoft-foundry/provider.ts)

Remaining risk / open question:

  • No after-fix Azure Foundry onboarding proof shows Claude deployments being skipped or rejected in a real discovered-resource flow.
  • The current PR head contains literal CHANGELOG.md conflict markers, so exact-head checks and merge readiness remain blocked.

Codex review notes: model gpt-5.5, reasoning high; reviewed against bc275573012b.

@clawsweeper clawsweeper Bot mentioned this pull request Apr 28, 2026
Open
@ottodeng ottodeng force-pushed the fix/foundry-filter-anthropic-deployments branch from d7fa841 to 4c0f392 Compare May 2, 2026 03:13
@ottodeng
Copy link
Copy Markdown
Contributor Author

ottodeng commented May 2, 2026

Pushed updates addressing review feedback:

[P2] Filter the persisted catalog too (dfa3a053da)

  • Added partitionFoundryDeployments in shared.ts as the single source of truth for separating supported (OpenAI-compatible) deployments from Anthropic ones.
  • selectFoundryDeployment now returns { selected, supported }. auth.ts uses that supported list when building discoveredDeployments, so mixed GPT+Claude resources no longer leak Claude entries into the saved models.providers.microsoft-foundry catalog after the picker hides them.

Tests (63efff4e4e)

  • partitionFoundryDeployments: mixed GPT+Claude, all-Anthropic, all-OpenAI cases.
  • selectFoundryDeployment: mixed resource persists only GPT entries + warns about unsupported, all-Anthropic resource throws actionable error, all-OpenAI resource is unchanged with no warning.

[P3] CHANGELOG (16b750f12c)

Verification on tip 16b750f12c:

  • pnpm test extensions/microsoft-foundry/index.test.ts → 42 passed (8 new).
  • pnpm check:changed → green (typecheck, oxlint, duplicates, runtime sidecar/import cycles, changelog attributions, etc.).

@clawsweeper clawsweeper Bot mentioned this pull request May 2, 2026
Open
6 tasks
@ottodeng
Copy link
Copy Markdown
Contributor Author

ottodeng commented May 3, 2026

Merged latest upstream/main (CHANGELOG conflict resolved by keeping both sides). Re-pushed.

@ottodeng ottodeng force-pushed the fix/foundry-filter-anthropic-deployments branch from 6f9fbe9 to 28bfd52 Compare May 3, 2026 05:13
@ottodeng
Copy link
Copy Markdown
Contributor Author

ottodeng commented May 5, 2026

Synced with upstream/main, CI green. Available for review.

ottodeng added 4 commits May 9, 2026 04:09
@ottodeng @BradGroux
fix(microsoft-foundry): filter Anthropic deployments during onboard
84bcd29 
The built-in microsoft-foundry provider only supports OpenAI-compatible
Foundry APIs (chat/completions, responses). Anthropic (Claude)
deployments on Azure AI Foundry use a different API shape
(/anthropic/v1/messages) that is not wired yet, causing silent 404
failures at runtime after apparently successful onboarding.

Changes:
- Add isAnthropicFoundryDeployment() to detect Claude model names
- Filter Anthropic deployments from the selection list during onboard
- Show an informative note with workaround (custom provider) when
  Anthropic deployments are skipped
- Provide a specific error message when only Anthropic deployments exist
- Add tests for the detection function

Fixes openclaw#60546
@ottodeng @BradGroux
fix(microsoft-foundry): use shared filter for picker and persisted ca…
1d73fb6 
…talog

Address PR review feedback: `selectFoundryDeployment` derived a local
`supported` list to drive the picker but the persistence path in
auth.ts still mapped the raw `resourceDeployments` into
`discoveredDeployments`, so mixed GPT+Claude resources hid Claude in
the picker yet still wrote it into the saved provider catalog as a
`microsoft-foundry/<deployment>` model that routes through /openai/v1.

- Add `partitionFoundryDeployments` in shared.ts as the single source
  of truth for filtering.
- `selectFoundryDeployment` now returns `{ selected, supported }` so
  callers can persist the same supported list the picker showed.
- `auth.ts` uses the supported list when building
  `discoveredDeployments`, keeping the picker and catalog in sync.
@ottodeng @BradGroux
test(microsoft-foundry): cover shared deployment filter for picker + …
5a898dd 
…persistence

Adds focused unit tests for the new partitionFoundryDeployments helper
and the picker/persistence contract returned by selectFoundryDeployment:
- mixed GPT+Claude resource: only GPT deployments persisted, Claude
  surfaced via the unsupported-deployment note
- all-Anthropic resource: actionable error path
- all-GPT resource: unchanged supported list with no warning note
@ottodeng @BradGroux
docs(changelog): note microsoft-foundry Anthropic onboarding guardrail
ae6567b
@BradGroux BradGroux force-pushed the fix/foundry-filter-anthropic-deployments branch from 28bfd52 to ae6567b Compare May 9, 2026 09:12
@BradGroux
Copy link
Copy Markdown
Member

BradGroux commented May 9, 2026

Maintainer refresh: rebased onto current origin/main and resolved the changelog attribution blocker.

Prepared head: ae6567bbf9818ed4695dba2079b204da3b55a80b

Local verification passed:

  • pnpm exec oxfmt --check --threads=1 CHANGELOG.md extensions/microsoft-foundry/auth.ts extensions/microsoft-foundry/index.test.ts extensions/microsoft-foundry/onboard.ts extensions/microsoft-foundry/shared.ts
  • pnpm check:changelog-attributions
  • pnpm vitest run extensions/microsoft-foundry/index.test.ts

Waiting on fresh GitHub CI before merge.

@openclaw-barnacle openclaw-barnacle Bot added the triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. label May 9, 2026
@BradGroux BradGroux mentioned this pull request May 9, 2026
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

size: M triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

[Bug]: microsoft-foundry provider selects Claude deployments but routes them through OpenAI Foundry endpoints

2 participants

@ottodeng @BradGroux