Medium severity — unbounded recursive tool loop.

This recursively calls call() when the model keeps requesting tools. A misbehaving model could cause infinite recursion / stack overflow. Consider adding a max iteration count. Spring AI's default ToolCallingManager has one internally, but since the loop is driven manually here, that limit is bypassed.

Test coverage added (ChatModelActivityImplTest, 10 tests). Ready to add loop limit — next up.

Done — converted recursive call to iterative loop with MAX_TOOL_CALL_ITERATIONS = 10 limit.

Reverted — removed the iteration limit and switched back to recursive internalCall() matching Spring AI's OpenAiChatModel pattern. Temporal's activity timeouts and workflow execution timeout already bound runaway tool loops.

Obviously will delete this prior to merging ;)

Is the primary reason for these being separate plugins because of spring configuration interaction? Otherwise I would think it makes more sense to have one with configurations.

Would it make more sense to use a SimplePlugin builder to create this? In other languages we would not need to manually override initializeWorker, I would expect there to be some way to use the simple plugin's registerActivitiesImplementations rather than the underlying worker.

Is there a good reason we are making local activities so primary?

Mmmm... this is not the approach I have taken elsewhere. I'm of the opinion that tools should execute in workflow context by default, where the user could define a tool which does various workflow operations without us needing to define special tool types for them. Child workflow, multiple operations, etc.

In the ASSISTANT branch, assistantMessage.getMedia().stream() is called without a null/empty guard. Spring AI messages elsewhere in this module use CollectionUtils.isEmpty(...) when reading AssistantMessage#getMedia() (e.g., ChatModelActivityImpl), which suggests getMedia() may be null. If a caller passes an AssistantMessage without media set, this will throw an NPE while converting the Prompt. Consider guarding with CollectionUtils.isEmpty(assistantMessage.getMedia()) (and treating null as empty) to keep ActivityChatModel.call() robust for user-supplied prompts.

The IllegalArgumentException message for unknown tool types doesn’t mention Nexus service stubs as a supported/recognized Temporal primitive, even though convertTools explicitly supports TemporalStubUtil.isNexusServiceStub(...) and converts via NexusToolUtil.fromNexusServiceStub(...). This makes the error misleading for users. Update the message to include Nexus service stubs (and ideally child workflow stubs as explicitly unsupported) so it matches actual behavior.

Injecting @Autowired(required = false) ChatModel primaryChatModel will still fail application startup when multiple ChatModel beans exist but none is marked @Primary (Spring will throw NoUniqueBeanDefinitionException before this bean method is invoked). Since the plugin already has a deterministic fallback (first entry in the injected map), consider changing this parameter to something that won’t fail under ambiguity (e.g., use an ObjectProvider<ChatModel> and catch NoUniqueBeanDefinitionException, or drop this injection entirely and always let SpringAiPlugin choose from the map).

workflowWithTools_replaysDeterministically doesn’t actually exercise the tool-calling path: StubChatModel always returns a final AssistantMessage with no tool calls, so none of the default tools (DeterministicTool/SideEffectTool wrappers) are invoked during the workflow run. That means the replay assertion isn’t validating determinism of tool execution. Consider adjusting the stub model to first return an assistant message containing tool call requests (and then a final message after tool responses) so this test covers the intended behavior.

Could this increase friction though if a Spring user is just trying to get started and doesn't realize they need to import the sdk as well? Is there a temporal-spring-ai-starter planned that would pull in the right transitive dependencies to help with easy onboarding? Maybe not necessary but just a thought

Probably clarify in the docs/readme the compatibility matrix for the module? (So - maybe not in this PR - but at least in the forthcoming docs PR)

If you do go ahead with this route, it looks like tests are lacking at the moment, is there a meaningful way to explicitly test adviseCall?

Does it make sense to cache this in terms of replayability? If the workflow is replayed in some way where the activity's server capabilities have changed, we'd get a stale value? Is that a realistic thing we need to worry about?

Can two MCP clients have the same name() in their ClientInfo? That would throw an IllegalStateException so we should handle that or validate or something

Should we warn users about this?

You always cast this to String (ChatModelActivityImpl.toSpringMessage() and ActivityChatModel.toAssistantMessage()). Should we just make this a String? If we tried to deserialize something into a non-String, we'd get a ClassCastException I think?

Nitpick here but technically this creates a ton of Double objects (1536+ dimensions for OpenAI)... consider using float[] or double[] in EmbeddingModelTypes to avoid boxing and reduce serialization payload size?