Kernel

[dinmukhamedm]

Note

Adds Kernel OpenTelemetry instrumentation with output formatters, registers it in tracing, and updates packaging/version to 0.7.21.

• OpenTelemetry:
  • Kernel instrumentation: New module opentelemetry/instrumentation/kernel/__init__.py wrapping BrowsersResource, ComputerResource (tool spans), ProcessResource (tool spans), PlaywrightResource.execute, and KernelApp.action (observed handlers with flush).
  • Formatters: Add screenshot_tool_output_formatter and process_tool_output_formatter in kernel/utils.py.
• Tracing Init:
  • Add KernelInstrumentorInitializer in _instrument_initializers.py and register Instruments.KERNEL in tracing/instruments.py.
• Packaging:
  • Bump version to 0.7.21 (pyproject.toml, version.py), add Python 3.14 classifier, include dev dep kernel>=0.18.0, and update build-system to uv_build>=0.9.7,<0.10.

^{Written by Cursor Bugbot for commit 98668f0. This will update automatically on new commits. Configure here.}

---

Important

Add Kernel OpenTelemetry instrumentation, update version to 0.7.21, and add new dependency.

• OpenTelemetry:
  • Add KernelInstrumentor in opentelemetry/instrumentation/kernel/__init__.py to trace BrowsersResource, ComputerResource, PlaywrightResource, ProcessResource, and KernelApp.action with async wrappers and error handling.
  • Add formatters in kernel/utils.py: screenshot_tool_output_formatter and process_tool_output_formatter for base64 decoding.
  • Register KernelInstrumentorInitializer in _instrument_initializers.py and add Instruments.KERNEL in instruments.py.
• Packaging:
  • Bump version to 0.7.21 in pyproject.toml and version.py.
  • Add dev dependency kernel>=0.18.0.
  • Update build system to uv_build>=0.9.7,<0.10 and add Python 3.14 classifier.

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

[ellipsis-dev]

Caution

Changes requested ❌

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

• Reviewed 509 lines of code in 6 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. pyproject.toml:144

• Draft comment:
  Ensure the updated uv_build version (>=0.9.7,<0.10) is compatible with your build and tests.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is asking the PR author to ensure compatibility of a dependency version with their build and tests. This falls under the rule of not asking the author to ensure or verify things, especially related to dependencies.

2. src/lmnr/opentelemetry_lib/opentelemetry/instrumentation/kernel/__init__.py:342

• Draft comment:
  Consider making the 'to_wrap' parameter in _wrap_app_action optional to avoid having to pass an empty dict.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

Workflow ID: wflow_OqvRT7XmS2XijO2I

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

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 9d4399c in 1 minute and 22 seconds. Click for details.

• Reviewed 34 lines of code in 2 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. src/lmnr/opentelemetry_lib/opentelemetry/instrumentation/kernel/__init__.py:222

• Draft comment:
  Use 'await' when calling the wrapped function in async wrapper, and pull the span_type from to_wrap. This makes the async instrumentation consistent with the sync version.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

2. src/lmnr/opentelemetry_lib/opentelemetry/instrumentation/kernel/utils.py:27

• Draft comment:
  Removed debug print to avoid unintended logging in production. This cleanup prevents leaking extra output.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, explaining why a debug print was removed. It doesn't provide a suggestion, ask for confirmation, or point out a potential issue. It violates the rule against making purely informative comments.

Workflow ID: wflow_adosyxyeNBjEUdSz

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

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 98668f0 in 1 minute and 42 seconds. Click for details.

• Reviewed 20 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 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/kernel/utils.py:31

• Draft comment:
  Using deepcopy here prevents modifying the original dict, which is good practice. However, if the dict only contains shallow (immutable) values, consider using a shallow copy (e.g., output.copy()) for better performance.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 15% vs. threshold = 50% The comment is about the change from output to deepcopy(output), which is indeed part of the diff. However, the comment is speculative ("If the dict only contains shallow values...") and suggests a conditional optimization without knowing the actual structure of the data. The author clearly chose deepcopy for a reason - likely because they need to avoid mutating the original dict (lines 32-35 show the dict is being modified). The comment doesn't provide strong evidence that shallow copy would be sufficient, and using shallow copy could introduce bugs if the dict contains nested structures. This is a speculative performance suggestion without clear evidence it's safe or necessary. The author added deepcopy for a reason - to avoid mutating the original dict. Without knowing the actual structure of the data being passed in, suggesting a shallow copy could introduce bugs. The performance concern is speculative and may not be significant in practice. The comment is speculative ("If the dict only contains...") and doesn't provide strong evidence that the change would be safe or beneficial. The author likely chose deepcopy deliberately to ensure no mutation of the original object, and without knowing the actual data structures involved, this suggestion could introduce subtle bugs. This comment should be deleted. It's a speculative performance optimization that starts with "If" and doesn't provide clear evidence that the change would be safe or necessary. The author chose deepcopy deliberately, and suggesting shallow copy without understanding the data structures could introduce bugs.

Workflow ID: wflow_XkYehWtcgXdQ7UjE

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