Skip to content

release: 0.64.0#114

Open
stainless-app[bot] wants to merge 3 commits into
mainfrom
release-please--branches--main--changes--next
Open

release: 0.64.0#114
stainless-app[bot] wants to merge 3 commits into
mainfrom
release-please--branches--main--changes--next

Conversation

@stainless-app
Copy link
Copy Markdown
Contributor

@stainless-app stainless-app Bot commented Jun 5, 2026

Automated Release PR

0.64.0 (2026-06-05)

Full Changelog: v0.63.0...v0.64.0

Features

  • Telemetry: expose opt-in categories + full event taxonomy (public API) (a1502dd)

This pull request is managed by Stainless's GitHub App.

The semver version number is based on included commit messages. Alternatively, you can manually set the version number in the title of this pull request.

For a better experience, it is recommended to use either rebase-merge or squash-merge when merging this pull request.

🔗 Stainless website
📚 Read the docs
🙋 Reach out for help or questions


Note

Medium Risk
Telemetry configuration and event category values change behavior and typing for stream consumers; integrators relying on old defaults or system/monitor_screenshot rules may need updates.

Overview
Release 0.64.0 bumps package metadata and syncs the SDK to a new OpenAPI spec. The substantive change is an expanded browser telemetry public surface.

Telemetry capture is now documented and typed as opt-in per category: only categories explicitly set to enabled=true are captured, with a documented default set (control, connection, system, captcha) when telemetry.enabled=true and no per-category overrides. BrowserTelemetryCategoriesConfig gains captcha, connection, control, screenshot, and system alongside the existing CDP categories, and create/update param docs reflect the new semantics.

The streamed event union grows with nine new event types (e.g. api_call, CDP/live-view connect/disconnect, captcha solve results, OOM kills, service crashes). Several existing events reclassify category: CDP monitor health events move from system to monitor, and monitor_screenshot uses screenshot instead of always-on behavior described previously. TelemetryStreamResponse docs now explain category-gated capture and that monitor health events follow CDP category enablement.

api.md exports the new types; browser API tests include the expanded telemetry category payloads in full-param create/update examples.

Reviewed by Cursor Bugbot for commit 0106bb5. Bugbot is set up for automated code reviews on this repo. Configure here.

@stainless-app
Copy link
Copy Markdown
Contributor Author

stainless-app Bot commented Jun 5, 2026

🧪 Testing

To try out this version of the SDK:

pip install 'https://pkg.stainless.com/s/kernel-python/a1502dd2639b97fb14ec57bfef5e37668b379db7/kernel-0.63.0-py3-none-any.whl'

Expires at: Sun, 05 Jul 2026 21:38:31 GMT
Updated at: Fri, 05 Jun 2026 21:38:31 GMT

@firetiger-agent
Copy link
Copy Markdown

Created a monitoring plan for this PR.

What this PR does: Publishes Python SDK v0.64.0, making 8 new browser telemetry event types available to SDK consumers and completing the per-category telemetry configuration API with 5 new category fields (captcha, connection, control, screenshot, system).

Intended effect:

  • New event type coverage in SDK: SDK consumers will receive and correctly deserialize api_call, captcha_solve_result, cdp_connect, cdp_disconnect, live_view_connect, live_view_disconnect, service_crashed, system_oom_kill events — baseline 0 (types were unknown); confirmed if telemetry streams handle them without validation errors after users upgrade.
  • API error rate (POST /browsers, PATCH /browsers): baseline 5xx 0–27/hr, 4xx ~8,000–17,000/hr; confirmed if no sustained elevation post-release.

Risks:

  • Category rename breaks existing consumersmonitor_* events changed from category="system" to category="monitor"; screenshot changed to category="screenshot"; alert if any customer reports missing monitor events or unexpected category values after upgrading.
  • Opt-in semantics change — previously omitted categories may have been treated as enabled by some consumers; alert if users report fewer-than-expected events post-upgrade.
  • POST /browsers 5xx regression — alert if Railway HTTP 5xx on api service exceeds 30/hr for 2+ consecutive hours (baseline: 0–27/hr).
  • API-SDK timing mismatch — new category keys or event types not recognized by an older server version; alert if HTTP 422 errors appear on browser create/update endpoints (baseline: ~0/hr).

Status updates will be posted automatically on this PR as monitoring progresses.

View monitor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants