chore(deps): bump h2 from 4.3.0 to 4.4.1 in /packages/python-sdk in the uv group across 1 directory - #1651
Conversation
Bumps the uv group with 1 update in the /packages/python-sdk directory: [h2](https://github.com/python-hyper/h2). Updates `h2` from 4.3.0 to 4.4.1 - [Changelog](https://github.com/python-hyper/h2/blob/master/CHANGELOG.rst) - [Commits](python-hyper/h2@v4.3.0...v4.4.1) --- updated-dependencies: - dependency-name: h2 dependency-version: 4.4.1 dependency-type: direct:production dependency-group: uv ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
dependabot
Bot
added
dependencies
🦋 Changeset detectedLatest commit: 225b19f The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Package ArtifactsBuilt from 24d5505. Download artifacts from this workflow run. JS SDK ( npm install ./e2b-2.38.2-dependabot-uv-packages-python-sdk-uv-a661626dcb.0.tgzCLI ( npm install ./e2b-cli-2.16.2-dependabot-uv-packages-python-sdk-uv-a661626dcb.0.tgzPython SDK ( pip install ./e2b-2.37.1+dependabot.uv.packages.python.sdk.uv.a661626dcb-py3-none-any.whl |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ef70caf3ec
ℹ️ 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".
| "black==26.3.1", | ||
| "e2b-openapi-python-client==0.26.2", | ||
| "datamodel-code-generator==0.64.0", | ||
| "datamodel-code-generator==0.72.2", |
There was a problem hiding this comment.
This bump makes uv run make generate-mcp use datamodel-code-generator 0.72.2 after make init, but repository make codegen still builds codegen.Dockerfile:24 with 0.64.0; the adjacent comment says these pins mirror so local output matches CI. Any future MCP regeneration can now produce different e2b/sandbox/mcp.py depending on whether the developer used the uv environment or the Docker codegen path, so either update the Dockerfile in the same change or leave this pin at 0.64.0.
Useful? React with 👍 / 👎.
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| codegen = [ | ||
| "black==26.3.1", | ||
| "e2b-openapi-python-client==0.26.2", | ||
| "datamodel-code-generator==0.64.0", | ||
| "datamodel-code-generator==0.72.2", | ||
| "protoc-gen-connectrpc==0.11.1", | ||
| "protoc-gen-py==0.1.1", | ||
| ] |
There was a problem hiding this comment.
🔴 This PR (nominally an h2 bump) also bumps datamodel-code-generator from 0.64.0 to 0.72.2 in pyproject.toml's codegen dev-dependency group, but codegen.Dockerfile:24 still pins 0.64.0 and was not updated. The comment directly above this group states pins mirror codegen.Dockerfile so local and CI codegen output match — this bump breaks that invariant.
Extended reasoning...
The bug: packages/python-sdk/pyproject.toml bumps the codegen dependency-group pin for datamodel-code-generator from 0.64.0 to 0.72.2 (an 8-minor-version jump), and uv.lock is updated to match. However, codegen.Dockerfile:24 still reads:
RUN pip install black==26.3.1 e2b-openapi-python-client==0.26.2 datamodel-code-generator==0.64.0 protoc-gen-connectrpc==0.11.1 protoc-gen-py==0.1.1
That line was not touched by this PR.
Why existing code doesn'''t prevent it: The comment directly above the codegen group in pyproject.toml (lines 43-47) is explicit about the intended invariant: "Pins mirror codegen.Dockerfile so local output matches CI ... keep the versions in sync." There is no automated check (lint/CI job) enforcing that these two pins stay identical — it'''s a documented convention that this PR silently violates. CLAUDE.md at the repo root reinforces the same expectation for codegen-related pins generally.
Code path that triggers it / step-by-step proof:
- A contributor runs
uv run make generate-api(or similar) locally after this PR merges.uvresolvesdatamodel-code-generatorper the updatedpyproject.toml/uv.lock, i.e. version0.72.2. - CI/Docker-based codegen instead builds from
codegen.Dockerfile, which still installsdatamodel-code-generator==0.64.0viapip install. datamodel-code-generatoris a code generator whose output (formatting, model emission, typing details) can and does change across an 8-minor version range.- If the local contributor regenerates code with 0.72.2 and commits it, CI running the Docker path with 0.64.0 would produce a diff against the committed output (or vice versa for CI-based regeneration), causing generated-code drift / CI mismatches that are confusing to debug because the two toolchains silently disagree.
Impact: No runtime/shipped-SDK behavior is affected today — the h2 bump itself is fine, and no generated files were touched by this PR. The blast radius is limited to the next time someone runs codegen: local and CI/Docker outputs can diverge, and whoever hits this will have to reverse-engineer why the generator behaves differently in the two environments, since the version pins now visibly disagree with the comment describing them as synced.
Fix: Either revert the datamodel-code-generator bump (it looks like an unrelated change swept in by Dependabot/the uv lockfile resolution alongside the h2 bump, given the PR title is "bump h2") or bump codegen.Dockerfile:24'''s datamodel-code-generator==0.64.0 to ==0.72.2 to match, keeping the two pins in sync per the documented invariant.
On severity: This doesn'''t break anything a user would hit today, and it'''s trivial to fix (one line in the Dockerfile, or drop the unrelated bump). But it directly and knowingly violates an explicit, documented invariant in the repo ("keep the versions in sync"), and the failure mode (silent generated-code drift, confusing CI diffs) is exactly the kind of thing that pin comment exists to prevent. All three independent verifiers reached the same conclusion with no refutations. I'''m filing as normal given it contradicts an explicit stated sync requirement, but flag this is close to the nit/normal boundary.
Bumps the uv group with 1 update in the /packages/python-sdk directory: h2.
Updates
h2from 4.3.0 to 4.4.1Changelog
Sourced from h2's changelog.
Commits
bc239afv4.4.192b925eadd test for duplicate host headers292a408reject duplicate Host headers in request headers04d3b87update changelog439b970prepare for next release cycle9a7ff74performance: remove consumed frames in place from data buffer (#1321)6cce763v4.4.0dfafda3Bump pytest from 8.4.2 to 9.0.3 (#1320)b45207cdependencies and packaging++c40145fparsecontent-lengthheaders according to RFC9110 grammar for numbers (1*DI...Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditionsYou can disable automated security fix PRs for this repo from the Security Alerts page.