Bug Report
Import path of package in question
github.com/Azure/azure-sdk-for-go/sdk/ai/azopenai
(Issue originates in the underlying github.com/openai/openai-go/v3/azure middleware)
SDK version
github.com/openai/openai-go/v3 v3.30.0 / azopenai latest (0.8.0)
Go version
go version go1.25.0 linux/amd64
What happened?
When attempting to use the Go SDK for Azure OpenAI Image Generation (DALL-E 3 / GPT-Image-1.5), the request fails in two specific ways depending on configuration:
- 404 Not Found (DeploymentNotFound): If the client is initialized normally, the SDK hits
POST /images/generations. Azure requires deployment-scoped routing: /openai/deployments/<deployment-name>/images/generations.
- 400 Bad Request: If we attempt to fix the routing by setting
ImageGenerateParams.Model to the Azure Deployment Name, the Azure middleware correctly rewrites the URL path, but the SDK also sends the deployment name in the JSON body's "model" field. Azure rejects this because it expects a canonical model name (e.g., gpt-image-1.5) in the body, or no model field at all, resulting in:
"Model not supported with Responses API. Supported models are: ['gpt-image-1', 'gpt-image-1-mini', 'gpt-image-1.5']"
What did you expect or want to happen?
The SDK should allow for Azure-compliant image generation requests where:
- The deployment name is used for URL path construction.
- The JSON body either omits the
model field or allows it to remain a canonical name (like gpt-image-1.5) while the URL path uses the deployment identifier.
How can we reproduce it?
- Initialize the client using Azure configuration:
client := openai.NewClient(
azure.WithEndpoint("https://<resource>.openai.azure.com/", "deployment-name"),
azure.WithAPIKey("apiKey"),
)
- Call
client.Images.Generate() with Model set to the deployment name.
- Observe the 400 error from Azure due to the
model field in the JSON payload.
- Call
client.Images.Generate() with Model set to gpt-image-1.5.
- Observe the 404 error because the middleware fails to inject the deployment name into the path.
Technical References (Internal Bottlenecks):
The issue stems from ImageService.Generate hardcoding the path and the way requestconfig executes:
- Hardcoded Path: The path is fixed to
images/generations, which doesn't account for Azure's deployment prefix requirements:
// vendor/github.com/openai/openai-go/v3/image.go:82
func (r *ImageService) Generate(...) {
path := "images/generations"
err = requestconfig.ExecuteNewRequest(ctx, http.MethodPost, path, body, &res, opts...)
}
- Model Field Conflict: The
model field is strictly validated against canonical names, making it unusable as a "deployment name" carrier for routing without triggering a 400 error:
// vendor/github.com/openai/openai-go/v3/image.go:1189
// The model to use for image generation. One of `dall-e-2`, `dall-e-3`, or a GPT
// image model (`gpt-image-1`, `gpt-image-1-mini`, `gpt-image-1.5`).
Model ImageModel `json:"model,omitzero"`
- Execution Order:
BaseURL is parsed before middleware application, meaning the path rewrite happens late in the stack and is dependent on the body content:
// vendor/github.com/openai/openai-go/v3/internal/requestconfig/requestconfig.go:387
cfg.Request.URL, err = cfg.BaseURL.Parse(strings.TrimLeft(cfg.Request.URL.String(), "/"))
// ... middleware applied after URL parsing
Reference to Official Confirmation
Microsoft Q&A Validation
This issue was discussed and confirmed by Microsoft External Staff (Moderator) 'https://learn.microsoft.com/en-us/users/karnamvenkatarajeswari/' in the official Microsoft Q&A forum. The moderator acknowledged that the Go SDK currently lacks the abstraction to align with Azure's deployment-based routing for image generation and suggested that the current behavior is a known limitation of the SDK layer.
Anything we should know about your environment.
This was tested against Azure OpenAI in eastus2 using api-version=2024-12-01-preview. Direct REST/Curl calls using the deployment-scoped URL and a minimal body (no model field) work perfectly, confirming the issue is isolated to the SDK's request construction.
Bug Report
Import path of package in question
github.com/Azure/azure-sdk-for-go/sdk/ai/azopenai(Issue originates in the underlying
github.com/openai/openai-go/v3/azuremiddleware)SDK version
github.com/openai/openai-go/v3 v3.30.0/azopenailatest (0.8.0)Go version
go version go1.25.0 linux/amd64What happened?
When attempting to use the Go SDK for Azure OpenAI Image Generation (DALL-E 3 / GPT-Image-1.5), the request fails in two specific ways depending on configuration:
POST /images/generations. Azure requires deployment-scoped routing:/openai/deployments/<deployment-name>/images/generations.ImageGenerateParams.Modelto the Azure Deployment Name, the Azure middleware correctly rewrites the URL path, but the SDK also sends the deployment name in the JSON body's"model"field. Azure rejects this because it expects a canonical model name (e.g.,gpt-image-1.5) in the body, or no model field at all, resulting in:"Model not supported with Responses API. Supported models are: ['gpt-image-1', 'gpt-image-1-mini', 'gpt-image-1.5']"What did you expect or want to happen?
The SDK should allow for Azure-compliant image generation requests where:
modelfield or allows it to remain a canonical name (likegpt-image-1.5) while the URL path uses the deployment identifier.How can we reproduce it?
client.Images.Generate()withModelset to the deployment name.modelfield in the JSON payload.client.Images.Generate()withModelset togpt-image-1.5.Technical References (Internal Bottlenecks):
The issue stems from
ImageService.Generatehardcoding the path and the wayrequestconfigexecutes:images/generations, which doesn't account for Azure's deployment prefix requirements:modelfield is strictly validated against canonical names, making it unusable as a "deployment name" carrier for routing without triggering a 400 error:BaseURLis parsed before middleware application, meaning the path rewrite happens late in the stack and is dependent on the body content:Reference to Official Confirmation
Microsoft Q&A Validation
This issue was discussed and confirmed by Microsoft External Staff (Moderator) 'https://learn.microsoft.com/en-us/users/karnamvenkatarajeswari/' in the official Microsoft Q&A forum. The moderator acknowledged that the Go SDK currently lacks the abstraction to align with Azure's deployment-based routing for image generation and suggested that the current behavior is a known limitation of the SDK layer.
Anything we should know about your environment.
This was tested against Azure OpenAI in
eastus2usingapi-version=2024-12-01-preview. Direct REST/Curl calls using the deployment-scoped URL and a minimal body (nomodelfield) work perfectly, confirming the issue is isolated to the SDK's request construction.