cloudwego / cloudwego/eino-ext
Azure: default AzureModelMapperFunc strips dots from the deployment name, docs say it strips commas
- 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
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