properly wrap content parts when gemini input is text

[dinmukhamedm]

Important

Wrap content payloads in lists when they are dictionaries in google_genai instrumentation and add a test for string content inputs.

• Behavior:
  • In google_genai/__init__.py, wrap content payloads in lists if they are dictionaries in _set_request_attributes() and _set_response_attributes().
  • Update version to 0.7.18 in pyproject.toml and version.py.
• Tests:
  • Add test_google_genai_string_contents in test_google_genai.py to verify handling of string content inputs.
  • Add cassette test_google_genai_string_contents.yaml for VCR testing.
• Misc:
  • Remove trailing whitespace in laminar.py.

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

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to b1a56cc in 2 minutes and 12 seconds. Click for details.

• Reviewed 234 lines of code in 6 files
• Skipped 0 files when reviewing.
• Skipped posting 6 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. src/lmnr/opentelemetry_lib/opentelemetry/instrumentation/google_genai/__init__.py:322

• Draft comment:
  Similarly, in _set_response_attributes the candidate content is wrapped. It would be helpful to document that this ensures that text inputs (when processed as dicts) are always represented as arrays in span attributes.
• 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% While the comment correctly identifies a pattern, it's not clear that this implementation detail needs documentation. The wrapping is a simple implementation detail that ensures consistent handling of payloads. Documentation about internal implementation details like this often becomes outdated and doesn't provide significant value to users of the code. The comment identifies a real pattern in the code. Perhaps having this documented would help future maintainers understand the code better and avoid breaking this consistency. While documentation can be helpful, this is a low-level implementation detail that's clear from the code itself. The pattern is simple enough that code comments would be redundant. The comment should be deleted as it requests documentation for an implementation detail that is already clear from the code itself.

2. src/lmnr/version.py:6

• Draft comment:
  Version bump to 0.7.18 looks correct. Ensure that any related documentation is updated accordingly.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is purely informative and asks the PR author to ensure documentation is updated, which violates the rules. It does not provide a specific code suggestion or highlight a potential issue with the code itself.

3. tests/test_google_genai.py:788

• Draft comment:
  Great new test 'test_google_genai_string_contents' that verifies when the input is a plain text string the instrumentation wraps it into a JSON list as expected.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

4. tests/test_google_genai.py:814

• Draft comment:
  Tests cover multiple scenarios (tool calls, multi-turn prompts, images, streaming, error handling). The comprehensive test suite is a strong point.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

5. src/lmnr/opentelemetry_lib/opentelemetry/instrumentation/google_genai/__init__.py:207

• Draft comment:
  Consider verifying that get_content returns only expected types (str, dict, or list). A type-check guard or comment could help clarify intended behavior.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

6. tests/cassettes/test_google_genai/test_google_genai_string_contents.yaml:4

• Draft comment:
  There appears to be an unintended newline in the JSON string for the systemInstruction "text" field, splitting what should likely be a single line into two. This may cause parsing issues. Please verify if the newline is intentional or if it should be escaped (e.g., using \n) to maintain valid JSON formatting.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a test cassette file which is in YAML format. YAML allows string continuation with proper indentation, which is what's happening here. The newlines are not actually in the JSON content - they're just how YAML formats long strings. The JSON would be properly parsed when loaded. The comment shows a misunderstanding of YAML syntax. Could there be an actual JSON parsing issue that I'm missing? Could the newlines cause problems in some edge case? No - this is a standard YAML test cassette file format. The content-length header shows 234 bytes which indicates the JSON is being properly formed. The response status 200 shows the request worked correctly. The comment should be deleted as it incorrectly identifies a YAML formatting feature as a JSON problem. The code is working as intended.

Workflow ID: wflow_Yi9odqBbNQwMV9Hs

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