chore(deps): bump monty from 0.0.19 to 0.0.21

[dependabot]

Bumps monty from 0.0.19 to 0.0.21.

Release notes

Sourced from monty's releases.

v0.0.21 - 2026-08-09

What's Changed

• Protocol version utils by @​samuelcolvin in pydantic/monty#697
• Bump version to v0.0.21 by @​samuelcolvin in pydantic/monty#696

Full Changelog: pydantic/monty@v0.0.20...v0.0.21

v0.0.20 - 2026-08-09

What's Changed

• Populate class __annotations__ (stringized) by @​rewitt94 in pydantic/monty#593
• tidy up max allocations remnants by @​davidhewitt in pydantic/monty#618
• fix npm audit warnings in monty js by @​davidhewitt in pydantic/monty#617
• Remove the ResourceTracker generic, always use ResourceTracker by @​samuelcolvin in pydantic/monty#613
• Track iterator types for GC so their cycles can't evade collection by @​rewitt94 in pydantic/monty#620
• Support function decorators by @​rewitt94 in pydantic/monty#590
• Support Path / Path and reflected str / Path in the / operator by @​samuelcolvin in pydantic/monty#621
• Update yanked spin 0.9.8 -> 0.9.9 and 0.10.0 -> 0.10.1 in Cargo.lock by @​samuelcolvin in pydantic/monty#623
• Bound nesting of class-body expressions walked before parsing by @​rewitt94 in pydantic/monty#624
• unify ExtFunction types by @​davidhewitt in pydantic/monty#598
• create cells for captured comprehension values by @​davidhewitt in pydantic/monty#605
• split all binary operators to be proper methods on PyTrait by @​davidhewitt in pydantic/monty#568
• split MontyIter into dedicated iterator types by @​davidhewitt in pydantic/monty#602
• implement file handle API for TS by @​davidhewitt in pydantic/monty#599
• clean up old opcodes, add dump version at the Rust level by @​davidhewitt in pydantic/monty#607
• Dispatch user-defined __iter__ / __next__ / __contains__ by @​rewitt94 in pydantic/monty#609
• Count the module's pending result in the strict ref-count check by @​rewitt94 in pydantic/monty#627
• Move py_contains onto PyTrait, fix in for bytes, add coverage by @​rewitt94 in pydantic/monty#625
• Implement os.listdir and filesystem wrappers in the os module by @​samuelcolvin in pydantic/monty#622
• Fix remaining py_contains issues from the #625 review by @​rewitt94 in pydantic/monty#628
• Add a ShutdownDump turn-ender and cheap frame classification by @​samuelcolvin in pydantic/monty#630
• Add itertools foundation with count and repeat by @​rewitt94 in pydantic/monty#632
• cleanups to some drop branches by @​davidhewitt in pydantic/monty#633
• Native @dataclass defined inside the sandbox by @​rewitt94 in pydantic/monty#626
• Add collections: deque, namedtuple, defaultdict, Counter by @​rewitt94 in pydantic/monty#608
• Bound the source-pattern text retained by the regex cache by @​samuelcolvin in pydantic/monty#644
• Bound native dataclass equality by the recursion-depth limit by @​rewitt94 in pydantic/monty#641
• Make monty-pool async end-to-end by @​samuelcolvin in pydantic/monty#639
• Refactor try/finally compilation onto a CPython-style frame-block stack by @​samuelcolvin in pydantic/monty#648
• Review Skills by @​samuelcolvin in pydantic/monty#651
• make benchmarks async properly by @​davidhewitt in pydantic/monty#652
• Shrink HeapData from 160 to 80 bytes by boxing large variants by @​samuelcolvin in pydantic/monty#636
• Apply new drop standards to the collections code by @​rewitt94 in pydantic/monty#653
• Add itertools adaptors: pairwise, compress, islice, chain, cycle by @​rewitt94 in pydantic/monty#635
• move py_set_attr onto PyTrait by @​davidhewitt in pydantic/monty#638
• implement NotImplemented and use it for user equality by @​davidhewitt in pydantic/monty#567
• Make bytes substring search linear and interruptible by @​rewitt94 in pydantic/monty#643
• Apply memory limit via custom allocator by @​samuelcolvin in pydantic/monty#646
• Windows path-parsing mount escape by @​rewitt94 in pydantic/monty#655
• attempt to configure telemetry via bindings or monty-runtime logfire by @​davidhewitt in pydantic/monty#662

... (truncated)

Commits

• 70fe3f5 Bump version to v0.0.21 (#696)
• 3634245 Protocol version utils (#697)
• dd6139a Bump version to v0.0.20 (#695)
• 738be95 Version the wire protocol independently of the package (#693)
• 5b5ffba Ci split test-rust (#694)
• 4512689 Send a WebSocket Close frame on worker teardown (#691)
• 44b3419 Collapse the two dump versions into one session dump format (#692)
• f38c847 rename files to mod.rs, stop annoying usize_field warnings (#690)
• 6babf25 Bound nested itertools adaptors by the recursion limit (#685)
• 2cc39dd Move monty version to types (#689)
• Additional commits viewable in compare view

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 rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	206870a	Commit Preview URL Branch Preview URL	Aug 13 2026, 09:36 AM

[claude]

Investigated this together with #2297. Two separate findings.

1. This PR cannot pass on its own. monty 0.0.19 depends on monty-types 0.0.19, so bumping only one of them leaves two monty-types versions in the graph and its result types stop unifying:

error[E0277]: the trait bound `monty_types::results::ExtFunctionResult:
              From<monty_types::ExtFunctionResult>` is not satisfied

That single cause is behind all ~22 failing checks here. monty and monty-types have to move together.

2. The combined bump is blocked by an upstream regression. I did the combined upgrade (#2298) and it compiles, but Monty 0.0.21 silently turns PythonLimits::max_memory into a no-op. max_memory is now evaluated from LIVE_MEMORY/BASELINE_MEMORY, which are only populated by monty-alloc installed as the process #[global_allocator]. Unarmed, probe_memory() is pinned at 0, so the limit can never fire — a 1M-item list allocation under a 2 MB cap exits 0 instead of being killed. The per-allocation on_grow/on_free hooks bashkit used to meter the VM were removed in the same change.

bashkit is a library and cannot install a global allocator on behalf of its embedders, so this is not fixable at our end. Evidence and options are in #2298.

Leaving this open rather than closing it so the upgrade isn't forgotten — but it should not be merged until the memory-enforcement question is resolved upstream, or an explicit decision is taken to narrow the guarantee.

---

Generated by Claude Code

[dependabot]

Looks like monty is no longer being updated by Dependabot, so this is no longer needed.

[chaliy]

Closing — superseded by #2300, which holds monty/monty-types at 0.0.19 on purpose.

Two problems here. The smaller one is that this PR and #2296 each bump one half of a version-locked pair, so both fail every check (no LimitedTracker in the root, expected trait, found struct ResourceTracker). Fixing that split locally surfaced the real one.

Monty 0.0.21 silently disables the Python sandbox's memory ceiling. It moves max_memory enforcement from in-process accounting (LimitedTracker::on_grow) to probe_memory(), which reads the LIVE_MEMORY/BASELINE_MEMORY statics. Those are written only by the separate monty-alloc crate, and only when it is installed as the process-wide global allocator — and neither monty nor monty-types depends on it. With it absent the statics keep their initial values, so probe_memory() is 0.saturating_sub(usize::MAX) == 0 and check_allocation — backing both max_memory and check_large_result — can never trip. No error, no warning.

Bashkit cannot supply that allocator: it is an embeddable library, so the global allocator belongs to the downstream binary, and bashkit-python is a CPython extension module where it is CPython's.

Verified by applying the full bump (both crates together, plus the ResourceTracker/ResourceLimits migration needed to compile) and running the resource-limit suites:

test python_security_tests::whitebox_resource_limits::successive_allocations_accumulate ... FAILED
test python_security_tests::whitebox_resource_limits::nested_list_bomb ... FAILED
test python_security_tests::whitebox_resource_limits::tight_memory_blocks_many_small_objects ... FAILED
test threat_model_tests::python_security_regressions::threat_python_pow_exhaustion ... FAILED

test result: FAILED. 9 passed; 4 failed; 1457 filtered out

Duration, recursion and print-cap tests pass in the same run, which localises the regression to allocator-backed memory.

#2300 adds dependabot ignore entries for both crates so this bump is not regenerated weekly, and records the blocker in knowledge/runtimes/python-builtin.md — including the API migration and the fact that 0.0.21 would let us drop the jiter [patch.crates-io] git pin (a real supply-chain win, but not worth taking a silent sandbox regression for). Worth revisiting once Monty exposes an embedder-usable memory bound.

---

Generated by Claude Code