Fix AnthropicChatOptions.timeout(Duration) being ignored outside model construction

[seeun0210]

Thank you for taking time to contribute this pull request!
You might have already read the contributor guide, but as a reminder, please make sure to:

• Add a Signed-off-by line to each commit (git commit -s) per the DCO
• Rebase your changes on the latest main branch and squash your commits
• Add/Update unit tests as needed
• Run a build and make sure all tests pass prior to submission

For more details, please check the contributor guide.
Thank you upfront!

---

Summary

Fixes #6604.

AnthropicChatModel.internalCall()/internalStream() never forwarded the effective AnthropicChatOptions.getTimeout() (whether set via ChatClient.Builder.defaultOptions() or a per-request ChatClient.prompt().options(...) override) into a com.anthropic.core.RequestOptions for the underlying Anthropic Java SDK call. Both call sites always used the SDK's default RequestOptions, so the only timeout that ever had any effect was the one baked into the shared AnthropicChatModel/AnthropicClient once, at construction time (via spring.ai.anthropic.timeout). This contradicts the documented usage, which shows .timeout(Duration) as a per-call AnthropicChatOptions setting.

Why this gap existed: The shared AnthropicClient/AnthropicChatModel bean is (correctly) built once at startup, so the timeout baked into its HTTP client is fixed at that point. When per-call AnthropicChatOptions.timeout(Duration) was documented as an override, the wiring to actually forward it into the SDK's per-call RequestOptions (which the SDK already supports without rebuilding the client) was never added — the two call sites just kept using the SDK's single-arg create()/createStreaming() overloads.

Why per-call overrides above 60s matter: Some calls legitimately need longer than the SDK's 60s default:

• web_search tool use, where the model can issue multiple search round-trips (query → fetch → read → continue generating) within a single API call.
• Generations with a large maxTokens, since output tokens are produced sequentially, so wall-clock time scales with output length.
• Claude Skills (AnthropicSkillContainer) invoking code execution to generate/edit complex xlsx/pptx/docx/pdf documents.

Without this fix, an app has no way to grant just those calls more time — raising spring.ai.anthropic.timeout globally is the only lever, and even then, an unconfigured/short construction-time timeout compounds silently across the SDK's automatic retries (default maxRetries: 2 → 3 attempts), so a call can fail after ~3× the configured timeout with no indication why.

• Adds a requestOptionsFor(Prompt) helper that resolves the merged (default + per-request) AnthropicChatOptions.getTimeout() into an explicit RequestOptions, passed to both messageService.create(params, requestOptions) and createStreaming(params, requestOptions).
• Updates AnthropicChatModelTests' Mockito stubs to match the new two-arg SDK call signature (mechanical change, no behavior change to the tests themselves).
• Adds AnthropicChatModelTimeoutTests with 3 cases: construction-time timeout bounds a call; a per-request ChatClient timeout overrides a too-short construction-time default; a ChatClient default-options timeout overrides a too-short construction-time default. All 3 fail without the fix (verified) and pass with it.

Test plan

• ./mvnw -pl models/spring-ai-anthropic test — full module suite (123 tests) passes
• New AnthropicChatModelTimeoutTests fail without the fix (confirmed via git stash on the production change) and pass with it
• Verified no real Anthropic API calls are needed — regression tests use MockWebServer with setHeadersDelay(...) for deterministic timing

[seeun0210]

While working on this, I noticed the same pattern likely exists in other provider modules — e.g. OpenAiChatModel.internalCall()/internalStream() also call this.openAiClient.chat().completions().create(request) / .createStreaming(request) with no com.openai.core.RequestOptions argument, even though the OpenAI Java SDK exposes the same create(params, RequestOptions) two-arg overload that this fix uses for Anthropic. So OpenAiChatOptions.getTimeout() set via ChatClient (default or per-request) is probably silently ignored there too, for the same reason.

If this fix direction looks right to maintainers, I'm happy to apply the same pattern to OpenAI (and check other provider modules for the same issue) in follow-up PRs.

[seeun0210]

Hi @sobychacko — thanks for triaging #6604 and assigning it to the 2.0.1 milestone!

Just wanted to flag that this PR already has a working fix + regression tests ready for review whenever you get a chance. Happy to adjust the approach if you'd prefer a different direction (e.g. bundling it with other providers as mentioned in my follow-up comment on this PR). No rush — just wanted to make sure it's on your radar alongside the issue.

Thanks!

[sobychacko]

Looks good. I added some minor nit-picks. You can also add your name (full real name) as an author to all the classes you modified in the PR.

[sobychacko]

Too much javadoc on a private method. Can you cut it down to what is absolutely necessary? We usually prefer this much detail only on the public API's.

[sobychacko]

In-line these comments instead of javadoc. This level of comment details are not required for private methods.

[sobychacko]

Use your full real name.

[seeun0210]

Thanks for the review @sobychacko — addressed all three points: trimmed the private-method Javadoc on resolveAnthropicOptions/requestOptionsFor to brief inline comments, and added my full name as an author to the classes touched in this PR. PTAL 🙏

On the follow-up I raised earlier: I went and confirmed the same pattern in OpenAiChatModel — internalCall()/internalStream() call .create(request)/.createStreaming(request) with no com.openai.core.RequestOptions, while OpenAiChatOptions exposes getTimeout(). So a timeout set via ChatClient (default or per-request) is silently ignored there too, identical to #6604. I also swept the other model modules and OpenAI is the only other one on this SDK two-arg create pattern.

Happy to fix it — would you prefer it bundled into this PR or as a separate follow-up PR (with its own issue)? Whatever is easier to review on your end.

[seeun0210]

Quick follow-up on my question above: I see #6648 has already been opened to propagate the timeout for the OpenAI models, so no need for a separate OpenAI PR from me — this one can stay scoped to Anthropic. 👍 I left a note over there linking the two since they share the same root cause.