refactor output parsing to allow for text part tool call not just raw string

[dinmukhamedm]

Important

Refactor output_message_from_genai_attributes() in spans.rs to handle text parts and tool calls, and add a test for output parsing.

• Behavior:
  • Refactor output_message_from_genai_attributes() in spans.rs to handle both text parts and tool calls, improving output parsing.
  • If both content parts and tool call parts are empty, return None.
• Tests:
  • Add test_parse_and_enrich_attributes_google_genai() in spans.rs to verify parsing of text parts and tool calls in output.

^{This description was created by for a53574d. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to a53574d in 2 minutes and 19 seconds. Click for details.

• Reviewed 302 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. app-server/src/traces/spans.rs:1109

• Draft comment:
  Consider trimming the string (e.g. using s.trim()) before checking for emptiness (s.is_empty() || s == """") to handle cases with extra whitespace.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a code quality suggestion that could theoretically catch edge cases with whitespace. However, looking at the context, this is part of a message content parser that's already handling JSON deserialization and specific message formats. The input string comes from JSON parsing, so it's unlikely to have meaningful leading/trailing whitespace that needs to be handled. The current checks for empty string and """" seem sufficient for the actual use case. I could be wrong about the source of the string - maybe there are cases where whitespace could appear. And handling whitespace is generally a good practice. While handling whitespace is good practice in general, in this specific context the string comes from parsed JSON where whitespace is already normalized. Adding trim() would add complexity without providing real value. Delete the comment. The suggestion is too minor and speculative for this context where we're dealing with JSON-parsed strings.

2. app-server/src/traces/spans.rs:1128

• Draft comment:
  The chaining of text parts and tool call parts always places text parts first. Confirm that this ordering meets the intended behavior for GenAI outputs.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to confirm the intended behavior of the code, which violates the rule against asking for confirmation of intention. It does not provide a specific suggestion or point out a clear issue with the code.

Workflow ID: wflow_yEKboRQ9DgIjefum

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}