Spring AI fixes its hard-coded 60-second stream timeout in a milestone release

The limit applied per call, according to the dev.to post that documented the regression ^[1]. On a stream, a per-call limit covers the whole turn. A response still producing tokens at second 59 was cut at second 60 ^[15].

The post's author wrote that the lesson keeps coming back in payments work: "the shortest timeout in the chain wins, and it's usually one you didn't set" ^[16]. The usual candidates are a load balancer, a gateway or an SDK default. This time it was a framework regression ^[18]. Sixty is the kind of number a person types. "When a call dies at a suspiciously round number of seconds, that's rarely a coincidence," the author wrote ^[17].

The post names 2.1.0-M1 as the release with the fix ^[4]. It does not mention a 2.0.x patch that carries it. For a service on a GA Spring Boot line, taking the fix puts two pre-release versions in the stack at once: the Spring AI milestone and Spring Boot 4.2.0-M2 ^[1].

The code change is smaller than the version jump suggests. According to the post, existing code keeps working. getText(), getMedia() and getToolCalls() are now views over the new parts, and the old constructors still produce the legacy order ^[11]. Streaming subscribers that read getText() see the same deltas as before ^[11].

The parts design is careful work. OpaquePayload holds provider data that has to be replayed unchanged, such as an Anthropic thinking signature or a Gemini thought signature ^[13]. Without a defined place for that data, the post says, a framework either drops it or grows a provider-specific hack. If it drops it, the model loses its train of thought partway through a tool loop ^[13]. UnknownPart keeps the raw JSON of block types the adapter does not model yet ^[14].

The parts work is also unfinished. In M1, only OpenAiResponsesChatModel produces and consumes parts natively. The other chat models get refactored in RC1 ^[7]. In my view the milestone is the right choice for a service whose turns regularly run past a minute and whose team already runs Boot milestones. A service that ships only on GA releases is different. There I would keep streaming turns under 60 seconds on 2.0.1 and take the fix from a later release, after the remaining adapters have had their parts refactor ^[7].