Use invoke_workflow as the AI operation type

[kycasdzxc]

Motivation

gen_ai.operation.name has a closed set of allowed values in the OpenTelemetry GenAI semantic conventions. Spring AI emits framework on the chat client span and on every advisor span, and framework is not one of them. The registry currently allows:

chat, generate_content, text_completion, embeddings, retrieval, fetch_response, create_agent, invoke_agent, execute_tool, invoke_workflow, plan, search_memory, create_memory, update_memory, upsert_memory, delete_memory, create_memory_store, delete_memory_store

invoke_workflow ("Invoke GenAI workflow") is the closest fit, and it matches how the code already describes these spans. The javadoc on ChatClientObservationContext reads "Context used to store metadata for chat client workflows."

The practical effect is that consumers validating against the convention skip or flag the attribute, so the chat client and advisor spans stay outside GenAI-aware tooling even though the model spans are picked up.

What this changes

• Adds AiOperationType.INVOKE_WORKFLOW and deprecates AiOperationType.FRAMEWORK, which no longer has a valid value to represent.
• ChatClientObservationContext and DefaultAdvisorObservationConvention use the new value.

AiOperationType is public API, so FRAMEWORK is deprecated rather than removed, with forRemoval = false. Happy to change that if you have a target version in mind.

One caveat on scope, since it is the weaker half of this change. invoke_workflow fits the chat client span cleanly: that span wraps the advisor chain, the model calls and the tool calls, which is what the conventions describe as a workflow. It is a looser fit for the individual advisor spans, which are steps within that workflow rather than workflows themselves. I applied it to both because leaving the advisor spans on framework would keep a value that is not in the registry at all, but scoping this to the chat client span, or dropping gen_ai.operation.name from the advisor spans entirely, are both easy changes if you prefer either.

Compatibility

This changes an emitted attribute value. Dashboards or alerts that filter on gen_ai.operation.name = framework for chat client or advisor spans would need to move to invoke_workflow. Calling it out because it is telemetry-visible rather than internal.

Keeping framework is also a legitimate choice. The GenAI conventions are still at Development stability, and declining to track a moving spec is a reasonable position for a released version. If that is where you land, say so and I will close this.

How this was found

Comparing two copies of the same Spring AI and MCP application, identical except for the OpenTelemetry instrumentation: one on spring-boot-starter-opentelemetry, one on Arconia. Arconia's GenAI convention already reports invoke_workflow for the chat client span, while the advisor spans keep framework because that value is set below the layer Arconia replaces.

Captured spans and the full comparison: https://github.com/kycasdzxc/spring-ai-otel-example/blob/main/FINDINGS.md

Not included

The chat client span's contextual name is built from the provider rather than the operation:

// DefaultChatClientObservationConvention#getContextualName
return "%s %s".formatted(context.getOperationMetadata().provider(), SpringAiKind.CHAT_CLIENT.value());

That yields spring_ai chat_client, where the span naming rule in the same conventions would suggest invoke_workflow chat_client. Left out to keep this focused on the attribute value. Happy to follow up separately if you want it changed.

See #6750