Skip to content

fix(deps): bump blaxel from 0.2.50 to 0.4.19 - #5440

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/uv/blaxel-0.4.19
Open

dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/uv/blaxel-0.4.19

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Oct 27, 2026 •

Copy link
Copy Markdown
Contributor

Bumps blaxel from 0.2.50 to 0.4.19.

Release notes

Sourced from blaxel's releases.

v0.4.1

Fixed

  • Job task exceptions now exit non-zero, so Blaxel executions are correctly marked failed instead of falsely reporting success (ENG-4261, #208).

Jobs with retries configured will now retry when their task raises. Tasks that perform non-idempotent work should remain retry-safe.

v0.4.0

⚠️ Behavior change — read before upgrading

Failed sandbox update_* and delete calls now raise SandboxAPIError instead of silently returning a malformed object.

Every generated control-plane API function returns Union[Error, T] | None, so an error status is a return value, not an exception. SandboxInstance.update_metadata, update_ttl, update_lifecycle, update_network and delete passed that response straight into cls(response), which does not type-check. A 403/404/500 therefore produced an instance wrapping an Error.

If you ignored the return value — the common shape — a failed write looked like a success:

  • update_ttl returned normally and the TTL was never applied
  • delete returned normally and the sandbox stayed alive and kept billing

If you used the return value, you hit AttributeError: 'Error' object has no attribute 'metadata' far from the real cause.

What this means for you

you impact
Your calls succeed No change. Same objects, same types, same behavior.
Your calls have been failing silently You now get exceptions. You were already broken — the update never applied, the delete never happened.
You wrote a workaround checking isinstance(result.sandbox, Error) This breaks. The call now raises before returning, so your check never runs.

Most notably: delete() on an already-deleted sandbox now raises where it previously returned quietly. If you delete in a finally: or a cleanup path, wrap it:

try:
    await sandbox.delete()
except SandboxAPIError:
    pass  # already gone

Also: delete() on an empty response now raises SandboxAPIError rather than ValueError.

This brings Python in line with the TypeScript SDK, which has always used throwOnError: true on these calls, and with Go, which returns idiomatic (res, err). Python was the only SDK swallowing these errors.

Fixes

  • fix(sandbox): propagate control-plane errors from update_*/delete (#206, ENG-4244)
    • all four update_* helpers and delete, in both the async and sync (SyncSandboxInstance) trees
    • delete no longer raises a misleading ValueError("Sandbox X not found") for what may have been a 500
    • VolumeInstance.delete had the same gap and now raises on both Error and empty responses
    • Reported by Albert at EvenUp, who also identified the correct fix: routing through the existing _unwrap_response() helper.

... (truncated)

Commits
  • edce017 sandbox: termination_grace_period_seconds and standby_grace_period_seconds on...
  • e9b63fd feat: add PostHog event tracking for SDK installs (ENG-2277) (#141)
  • 09cf277 Add workspace secrets (SecretInstance.set/list/delete) (#275)
  • b503846 feat(customdomains): regenerate client with spec.validationMethod and add opt...
  • c921c88 feat(image): choose the build region on build() (#281)
  • 4f86a75 feat(image): name build sizes build_memory and build_volume (#280)
  • bedbc75 fix(image): only send build headers the upload URL was signed for (#279)
  • 0a61fd5 feat(image): set build worker memory and volume on build() (#278)
  • 9b95667 test: align lifecycle tests with the 5m minimum sandbox TTL (#277)
  • d6433ee chore: regenerate SDK clients from latest API definitions (#276)
  • Additional commits viewable in compare view

@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 27, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-27T19:18:09.491763Z 0818cbf New commits
🔒 Security Review ✅ Completed 2026-10-27T19:20:11.270250Z 0818cbf New commits
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 14a7509704

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread uv.lock
[[package]]
name = "mcp"
version = "2.3.0"
version = "1.30.0"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Keep MCP v2 in the main lock

When CI or contributors install the all-extras environment from this lock, this downgrade makes MCP_V2 false and causes the entire tests/mcp/test_mcp_v2_http.py suite to skip. The separate integration profile only pins MCP 1.x versions, so this change removes the repository's MCP v2 coverage even though pyproject.toml still supports MCP 2 and ordinary users can resolve it; retain MCP 2.3 in the main environment or avoid the Blaxel update until its constraint can coexist with that coverage.

AGENTS.md reference: AGENTS.md:L19-L19

Useful? React with 👍 / 👎.

@jbeckwith-oai jbeckwith-oai left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocking dependency conflict: Blaxel 0.4.19 explicitly requires mcp>=1.9.4,<2.0.0 (the upstream manifest explains that its server subclasses the MCP 1.x FastMCP API). Resolving blaxel==0.4.19 together with the current mcp==2.3.0 fails. This PR therefore downgrades the main all-extras lock to MCP 1.30.0, breaks the typed MCP 2 test fixtures, and removes MCP 2 HTTP coverage; CI currently has eight failing jobs.

Please keep this PR open until an upstream Blaxel version can coexist with MCP 2, or provide a separately reviewed environment/CI split that preserves MCP 1 and MCP 2 coverage without overriding upstream constraints. The upstream default branch currently retains the same <2 cap. This update is not ready to merge.

@markstuart-oai markstuart-oai left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 14a7509704159f1284e9c8351d5650275578ce8c. The existing MCP v2 coverage finding still applies. The lock selects MCP 1.30 instead of 2.3, so the regular all-extras environment skips all 16 tests in tests/mcp/test_mcp_v2_http.py. The explicit compatibility matrix tests MCP 1.x; the separate packaging lanes do not run this transport suite. MCP 2 remains supported by the published requirement. Preserve an explicit MCP 2 transport-test lane without the incompatible Blaxel extra, or defer this bump until the dependencies can coexist.

I am referencing the existing inline finding rather than duplicating it. Source-only review; no dependencies were installed and no candidate code was executed. Hosted typecheck and seven test jobs failed on this head; those are readiness evidence, not additional code findings. I did not independently verify upstream package contents or live Blaxel behavior.

Bumps [blaxel](https://github.com/blaxel-ai/sdk-python) from 0.2.50 to 0.4.19.
- [Release notes](https://github.com/blaxel-ai/sdk-python/releases)
- [Commits](blaxel-ai/sdk-python@v0.2.50...v0.4.19)

---
updated-dependencies:
- dependency-name: blaxel
  dependency-version: 0.4.19
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot force-pushed the dependabot/uv/blaxel-0.4.19 branch from 14a7509 to 0818cbf Compare October 27, 2026 19:17

This branch has not been deployed

No deployments
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.

2 participants