Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

temporal-spring-ai: a provider 429 fails the chat activity on the first attempt

オープン
  • 何か問題がありますか？
#3,121 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
38/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
java, spring
領域
backend

調査の方向性

Start with ActivityChatModel.java:111-114 and the reported ProviderRateLimitRetryTest cases; the issue does not give the test's file path. Compare the activity's retry behavior with Spring AI's default handling of 429 and its inner retries. The issue describes possible approaches but leaves the policy to the team; done should address the reported 429 and 503 cases, including the Retry-After and insufficient_quota distinction.

索引モデルが issue の本文から書いたものです。

説明

Expected Behavior

A rate-limited LLM call (HTTP 429) through ActivityChatModel is retried by Temporal with backoff. sdk-python's OpenAI Agents integration already treats 429 as retryable and passes the provider's retry delay through (temporalio/sdk-python#1796).

Actual Behavior

The activity fails on attempt 1 with RETRY_STATE_NON_RETRYABLE_FAILURE. Spring AI's default error handlers, both the plain builder default and the Boot auto-configured one, turn every 4xx, 429 included, into NonTransientAiException (RetryUtils in Spring AI 1.1.0), and ActivityChatModel puts that type in doNotRetry by default (ActivityChatModel.java:111-114).

A related interaction on 5xx: Spring AI's own RetryTemplate (10 attempts, backoff up to 3 minutes) runs inside the activity, so a persistent 503 can send up to 30 requests across Temporal's 3 attempts. The activity has a 2-minute start-to-close and no heartbeat, so a timed-out attempt can keep calling the provider while later attempts run. sdk-python turned off Botocore's inner retries for its default Strands Bedrock model for a similar reason (temporalio/sdk-python#1797).

Steps to Reproduce the Problem

  1. Point a real OpenAiChatModel at a local stub that returns 429 with Retry-After: 7, register it with ChatModelActivityImpl, and call it from a workflow through ActivityChatModel.forDefault().
  2. The stub sees one request; the workflow gets ActivityFailure caused by ApplicationFailure of type NonTransientAiException, attempt 1.
  3. With a 503 stub and Spring AI's backoff shortened to milliseconds, the stub sees 30 requests.

I have this as a test (ProviderRateLimitRetryTest, five cases, including Boot-equivalent defaults and spring.ai.retry.on-http-codes=429). For a fix I'd rather not parse exception messages, but Spring AI's handlers throw NonTransientAiException with only a message, so the status survives only in the message and the headers are gone by the time the activity sees it. The OpenAI path could instead use a response error handler, scoped to the client Temporal calls, that keeps status, headers and the error body; the activity can then retry rate limits with Retry-After as the next delay and leave insufficient_quota 429s non-retryable, since backoff won't fix a billing limit. Whether the module should also turn off Spring AI's inner retry for calls it wraps seems like your team's call; I'll follow whichever direction you prefer.

Specifications

  • Version: sdk-java main (be01e60a), Spring AI 1.1.0
  • Platform: JDK 21, macOS
主要言語
Java
スター
433
フォーク
257
平均マージ
2日 20時間
マージ済み PR（30日）
20

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

temporalio/sdk-java のほかの issue

temporalio/sdk-java の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。