openai-agents: Handle various types of span_data.response.output parts

[adammw]

Description

Handle various defined types of span_data.response.output parts, and preference parsing the parts over using the consolidated output_text attribute. Some finish_reason logic has also been touched, however I cannot find documentation that they have ever been returned from the Responses API.

OpenAI Message Part Type	GenAI/OTel Part Type	Name
message	text†	—
message (refusal)	refusal*	—
reasoning	reasoning	—
compaction	compaction*	—
file_search_call	tool_call	file_search
function_call	tool_call	function_name
web_search_call	tool_call	web_search
computer_call	tool_call	computer
image_generation_call	tool_call_response	image_generation
code_interpreter_call	tool_call + tool_call_response	code_interpreter
local_shell_call	tool_call	local_shell
shell_call	tool_call	shell
shell_call_output	tool_call_response	shell
apply_patch_call	tool_call	apply_patch
apply_patch_call_output	tool_call_response	apply_patch
mcp_call	tool_call + tool_call_response	mcp_call
mcp_list_tools	tool_call + tool_call_response	mcp_list_tools
mcp_approval_request	tool_call	mcp_approval_request
custom_tool_call	tool_call	tool_name
(fallback: content string attribute)	text	—

†text schema does not define annotations which are added as a custom key to preserve as much metadata as possible
*custom/non-standard - no equivalent exists in current GenAI Semantic Conventions schema

Fixes #4185

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• Updated unit tests to exercise new codepaths
• Manually executed with OpenAI Web Search tool and confirmed tool_call parts in the OTel trace output.

Does This PR Require a Core Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[kylehounslow]

Seems that when include_sensitive_data=False, the arguments here become {"queries": ["readacted"]} (a dict wrapping a list), but when True, getattr(item, "queries", None) returns a bare list.
Question:

• Would consumers parsing this output see different shapes depending on the sensitivity setting? Should the Truepath also wrap in {"queries": ...} to keep the structure consistent?

[adammw]

think this was a typo or confusion of the scope of the if statement, added brackets to make it more obvious. the shape should remain the same.

[kylehounslow]

think this was a typo or confusion of the scope of the if statement, added brackets to make it more obvious. the shape should remain the same.

Thanks for the quick fix, it's clear to me now!

[adammw]

Turns out none of this is required - when include_sensitive_data=False the method never gets called so all this logic can go.

[kylehounslow]

nit: "readacted" → "redacted"? Looks like this may be inherited from the existing codebase, so maybe a separate cleanup PR if the project wants to address it

[kylehounslow]

Nice coverage of all the output types! Related to my comment above:
Since the instrumentor defaults to capture_message_content=SPAN_AND_EVENT (i.e. include_sensitive_data=True) when no kwarg is passed, seems all these assertions exercise the non-redacted path. Would it be worth adding a companion test with capture_message_content=False to verify the redaction paths produce the expected shape for a few of the more complex types (e.g., mcp_call, code_interpreter_call)?

[adammw]

Added the test_response_span_records_redacted_response_attributes test but the redaction is basically absolute - the output message attribute is not included at all - so none of that code is necessary.

[adammw]

Speaking of output shape, this will vary here depending on sensitivity, but I couldn't think of a better way to do it.

[kylehounslow]

Ack, probably unavoidable here without adding a lot of complexity. I think consumers would need to handle both cases regardless. Not a blocker.