Workspace.rm recursive: replace LIKE pattern with range scan

[teobucos]

Reproduction

Using @cloudflare/shell Workspace backed by D1, create a directory shaped like an Open Agent Skill:

• SKILL.md
• scripts/setup.mjs
• references/readme.md
• assets/sample.txt

Then call workspace.rm(path, { recursive: true }) or a wrapper that delegates to it.

Observed

D1 can reject the recursive delete with:

D1_ERROR: LIKE or GLOB pattern too complex: SQLITE_ERROR

The failing path is deleteDescendants(dirPath), which deletes descendants with WHERE path LIKE ? ESCAPE ?.

Suggested fix

Use a prefix range scan instead of SQLite LIKE/ESCAPE pattern matching:

await this.sql.run(
  `DELETE FROM ${T} WHERE path = ? OR (path > ? AND path < ?)`,
  dirPath, `${dirPath}/`, `${dirPath}/\uFFFF`
);

The same range predicate can be used when collecting R2 keys before deletion. This avoids the LIKE complexity path and preserves prefix semantics for normalized Workspace paths.

[kiwigitops]

I tested a small patch for this path here:
kiwigitops/agents@main...kiwigitops:agents:fix-workspace-rm-range-scan

One important detail: the lower bound should be ${dirPath}/, not dirPath; otherwise similarly prefixed siblings like /skill-sibling.txt sort inside the range and get deleted. The branch applies the range predicate to both R2 key collection and SQLite deletion, and adds a regression that rejects any LIKE query during recursive rm while preserving that sibling.

[adawang1210]

I also ran into this and put together a fix: adawang1210#1 (branch adawang1210:fix/issue-1539-rm-range-scan).

It overlaps with #1716 on the core change — both replace the LIKE ? ESCAPE ? queries in deleteDescendants with the half-open range [${dirPath}/, ${dirPath}0), applied to both the R2-key SELECT and the row DELETE, with the same '0'-successor upper bound. Two things distinguish my version:

1. An executable regression test for the astral-plane upper bound. fix(shell): use range scans instead of LIKE in Workspace rm/glob #1716 explains in prose why ${dirPath}0 is preferred over the ${dirPath}/� sentinel suggested in this issue's description, but nothing in its test suite would fail if someone "simplified" back to the sentinel. My branch adds a test that writes /dir/😀.txt and /dir/😀sub/nested.txt and asserts rm -r /dir actually deletes them — under a � upper bound those paths sort above the sentinel (U+1F600 encodes as F0 9F 98 80, which compares greater than EF BF BF under BINARY collation) and would silently survive the delete. Since the issue text itself recommends the sentinel, that regression is plausible and is now pinned by CI rather than by a PR description.

2. Strictly minimal scope. Only deleteDescendants changes; glob() and the escapeLike/LIKE_ESCAPE helpers are untouched. The diff maps 1:1 to the failure path reported here, which keeps the review surface small and makes the change trivially revertable. fix(shell): use range scans instead of LIKE in Workspace rm/glob #1716's glob() hardening and dead-code removal are reasonable, but they extend the same PR to a second query path with no reported failure — arguably better split into a follow-up.

In short: #1716 is the broader cleanup; my branch is the conservative fix for exactly the reported bug, plus a test that locks in the one subtle correctness decision (the upper-bound choice) that both fixes depend on. Happy for either to land — if #1716 is preferred, I'd suggest cherry-picking the astral-plane regression test from my branch. All 235 shell tests pass on my branch, including the existing %/_ LIKE-injection security tests.