fix(py-sdk): count extended-slice targets correctly in DynArray 🐛

[kriss39]

What

DynArray.__setitem__ with an extended slice (step other than 1) counts its targets as (stop - start) // step, which undercounts whenever (stop - start) % step != 0. The surplus values then fall through to the insert branch, so the array grows and its tail is reordered; with fewer values than targets a bare StopIteration escapes. list rejects a size mismatch on an extended slice with ValueError; DynArray silently deleted or inserted instead.

arr[:] = [str(i) for i in range(10)]
arr[0:5:2] = ['a', 'b', 'c']
# list     -> ['a','1','b','3','c','5','6','7','8','9']
# DynArray -> ['a','1','c','b','3','4','5','6','7','8','9']   (11 elements)

__getitem__ and __delitem__ already handle these slices correctly; only assignment was affected. The state is wrong the same way on every validator, so this is a contract data-integrity bug rather than a consensus split.

Change (executor line v0.3, runners/genlayer-py-std)

• storage/dyn_array.py: count targets with len(range(start, stop, step)) and raise ValueError on a size mismatch for extended slices, matching list.
• tests/test_storage_vec.py: parametrized cases for positive/negative extended slices and the size-mismatch rejection. The existing test_setitem_slice never reached this path (it always assigns 5 values and returns early when list raises).
• runners/support/versions/current.nix: refreshed genlayer-std, py-genlayer, py-genlayer-multi hashes.

Executor commit: kriss39/genvm-executor@7df2d9c on pr/v0.3/fix/dynarray-extended-slice (rebased onto the current pinned 7e0936a).

Verification

• runners/genlayer-py-std: pytest tests --ignore=tests/embeddings → 976 passed, 1 failed (test_render_rejects_malformed_image, PIL not installed in my venv — unrelated). The new cases fail 7/8 on the unpatched code and pass with the fix.
• Differential fuzz against list (random get/set/del slice sequences): 1030/3000 mismatches before, 0 after.
• ruff format / ruff check clean on the changed files.
• Runner hashes: I cannot run hash-updater.py on this machine (no nix, and the repo does not build runners on macOS). Instead I reproduced the content-addressing locally — make-zip.py under Python 3.13 over the cleanSource-filtered src/ plus runner.json, then the Depends uids for the two wrappers — and confirmed it yields the three hashes currently committed bit-for-bit before applying the same procedure to the patched tree. Please treat the #runners-all nix build as unrun on my side; if it reports a mismatch I will update from the got: values.
• Not built here: the Rust executor crate (unchanged by this PR).

v0.2.x does not vendor the Python runner sources, so no pr/v0.2/... branch.

Independent of the other two PRs I opened today; whichever current.nix change lands second I will rebase and recompute.

[github-actions]

GenVM PR actions

Tick a box to run it (the box unticks itself when handled). Actions only run while the PR has the ci-safe label.

• Force run full tests
• Provision executor PRs

Commands

• /genvm-run-tests — run full tests once for the current manager snapshot
• /merge — queue the exact manager snapshot through the App-owned E2E merge train

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Repository: genlayerlabs/genvm-manager/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 822875c2-98b7-4608-b163-58e77928122a

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[kriss39]

@kp2pml30 gentle ping on this one and #38, #39, #40 when you have time.

[kp2pml30]

thanks for finding a bug, but I am unsure if we can change the hash now, so I am holding this PR for now. I will think more about it