PR #71708: fix(image-gen): raise default Azure OpenAI image timeout to 600s

• Repository: openclaw/openclaw
• Author: Sanjays2402
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/71708

Description (problem / solution / changelog)

Summary

Fixes #71705. Azure OpenAI image generation (e.g. gpt-image-2) routinely takes 5+ minutes per request, but image-generation-provider.ts applies the same 180s default timeout that public OpenAI uses. As a result, otherwise-valid Azure image generations are aborted by OpenClaw even though the same request succeeds via the official Python SDK after ~394s, and via OpenClaw itself when timeoutMs=600000 is explicitly passed.

Change

• Adds DEFAULT_AZURE_OPENAI_IMAGE_TIMEOUT_MS = 600_000.
• resolveOpenAIImageTimeoutMs(timeoutMs, { isAzure }) now picks the Azure-aware default when no caller-provided timeout is set.
• The Azure detection (isAzureOpenAIBaseUrl) is already computed at the call site, so the change is one parameter.

Behavior

Also tightens the resolver to ignore non-finite / non-positive timeoutMs values instead of accepting them.

Risk

Low. No public API change; explicit caller timeouts still win; the public OpenAI path is byte-identical. Only the unset-timeout Azure case behaves differently, which is the bug being fixed.

Tests

Touched a single internal helper used by the existing image-gen path; no test changes needed for the helper itself, and existing image-generation tests still pass against the updated signature (the options arg is optional).

Closes #71705.

Changed files

• extensions/openai/image-generation-provider.ts (modified, +13/-3)

---

PR #71797: fix(openai): extend Azure image timeout

• Repository: openclaw/openclaw
• Author: steipete
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/71797

Description (problem / solution / changelog)

Summary

• Problem: Azure gpt-image-2 image generations can take longer than OpenClaw's shared 180s OpenAI image timeout.
• Why it matters: deployment-scoped Azure image requests can now have the right request shape but still fail unless users manually pass a large timeoutMs.
• What changed: Azure image-generation calls on recognized Azure OpenAI hosts now default to 600s while explicit timeoutMs still wins.
• What did NOT change (scope boundary): public OpenAI, OpenAI-compatible proxy, and Codex image timeout defaults stay unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #71705
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: extensions/openai/image-generation-provider.ts resolved every direct OpenAI image request through the same DEFAULT_OPENAI_IMAGE_TIMEOUT_MS = 180_000, including Azure deployment-scoped image generation.
• Missing detection / guardrail: Azure image request-shape coverage asserted endpoint/auth/body behavior but did not assert the Azure timeout default or explicit override.
• Contributing context: #71705 reports Azure gpt-image-2 succeeding with timeoutMs=600000 and via the official SDK after roughly 394s.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/openai/image-generation-provider.test.ts
• Scenario the test should lock in: recognized Azure image-generation hosts get a 600s default timeout and explicit timeoutMs overrides it.
• Why this is the smallest reliable guardrail: the timeout is resolved inside the provider request adapter before transport.
• Existing test that already covers this (if any): Azure request-shape test now also covers the default timeout.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Azure OpenAI image-generation requests on recognized Azure hosts now wait up to 600s by default. Users can still override with per-call timeoutMs.

Diagram (if applicable)

N/A

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22 / pnpm
• Model/provider: OpenAI provider, Azure OpenAI image-generation path
• Integration/channel (if any): image generation tool/provider
• Relevant config (redacted): Azure models.providers.openai.baseUrl

Steps

1. Configure models.providers.openai.baseUrl to a recognized Azure OpenAI host.
2. Generate an image using an Azure deployment name such as gpt-image-2-1.
3. Observe provider transport timeout handling.

Expected

• Azure image generation gets enough default timeout budget for slow gpt-image-2 generations.
• Explicit timeoutMs still overrides the default.

Actual

• Before: default path used 180s for Azure and could abort before Azure finished.
• After: Azure image-generation path uses 600s unless overridden.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios:
  • pnpm test extensions/openai/image-generation-provider.test.ts
  • pnpm check:changed
• Edge cases checked: explicit Azure timeoutMs override remains honored; non-Azure default path unchanged by code path.
• What you did not verify: live Azure generation, because this environment does not have the reporter's Azure deployment/API key.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: longer default waits can keep a slow Azure image request open for longer.
  • Mitigation: scoped only to recognized Azure image-generation hosts, and users can still pass a smaller timeoutMs.

Changed files

• CHANGELOG.md (modified, +3/-0)
• docs/providers/openai.md (modified, +2/-0)
• extensions/openai/image-generation-provider.test.ts (modified, +29/-0)
• extensions/openai/image-generation-provider.ts (modified, +10/-3)