cloudwego / cloudwego/eino-ext

Azure: default AzureModelMapperFunc strips dots from the deployment name, docs say it strips commas

Open
#939 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
811
Forks
368
Avg merge
16h 22m
Merged PRs (30d)
13

Description

## What happens

With `ByAzure: true` and a deployment whose name contains a dot, the request goes to a deployment that does not exist:

```
POST https://.services.ai.azure.com/openai/deployments/gpt-56-luna/chat/completions?api-version=2024-10-21
→ 404 The API deployment for this resource does not exist.
```

The configured model was `gpt-5.6-luna`. The dot is removed before the name reaches the url.

```go
openai.NewChatModel(ctx, &openai.ChatModelConfig{
Model: "gpt-5.6-luna", // the deployment name in the portal
APIKey: key,
BaseURL: "https://.services.ai.azure.com",
ByAzure: true,
APIVersion: "2024-10-21",
})
```

## Why

`AzureModelMapperFunc` is documented in `libs/acl/openai/chat_model.go` as

> Optional for Azure, remove [,:] from the model name by default.

but the default in the underlying client removes `[.:]`, a dot rather than a comma:

```go
// meguminnnnnnnnn/go-openai@v0.1.2 config.go:72
AzureModelMapperFunc: func(model string) string {
return regexp.MustCompile(`[.:]`).ReplaceAllString(model, "")
},
```

So the documented character class and the implemented one disagree, and the one that is actually stripped is the one that appears in real model names.

## Impact

I assume the intent is the historical Azure convention where `gpt-3.5-turbo` is deployed as `gpt-35-turbo`, because deployment names could not contain dots. Foundry deployments can contain dots now, and a caller who passes the exact name shown in the portal gets a 404 with no hint that the name was rewritten. The failure is easy to misread as a wrong endpoint or a missing deployment rather than a client side transformation.

The workaround is a one line identity mapper, once you know to look:

```go
AzureModelMapperFunc: func(model string) string { return model },
```

## Suggestion

Any of these would have saved the debugging, in rough order of preference:

1. Do not transform by default. A deployment name is an identifier the user copies from the portal, so passing it through unchanged is the least surprising behaviour, and callers who rely on the `gpt-3.5-turbo` convention can opt in with a mapper.
2. Keep the default but fix the doc comment to say `[.:]`, and mention it in the Azure section of `components/model/openai/README.md`, where it is not mentioned at all today.
3. Log at debug level when the mapper changes the name, so the rewritten deployment shows up next to the 404.

Happy to send a PR for whichever of these you prefer.

Versions: `eino-ext/components/model/openai v0.1.13`, `eino-ext/libs/acl/openai v0.1.17`, `eino v0.9.13`.

---
🤖 Generated with [Claude Code](https://claude.com/claude-code)

Contributor guide

Open the contributing guide

Research direction

Read libs/acl/openai/chat_model.go and compare its AzureModelMapperFunc documentation with the default in the underlying client’s config.go. Check the Azure guidance in components/model/openai/README.md, then clarify which behavior is intended; done means the mapper behavior, documentation, and regression coverage consistently address deployment names containing dots.

Written by the indexing model from the issue text.

Assessment

Tech stack
azure, go
Domain
api, backend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.