Skip to content

fix(artifacts): name the rejected segment and reason for unsafe patch paths - #1159

Open
mrthankyou wants to merge 2 commits into
mainfrom
fix/workspace-patch-segment-diagnostics
Open

mrthankyou wants to merge 2 commits into
mainfrom
fix/workspace-patch-segment-diagnostics

Conversation

@mrthankyou

@mrthankyou mrthankyou commented Sep 25, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

normalizeWorkspacePatchPath rejected unsafe workspace patch paths with only:

workspace patch file path contains an unsafe path segment

It named neither the path, the segment, nor the reason, so a segment over the 128-character cap looked identical to one with a disallowed character (#987). It now reports all three:

workspace patch file path "test/bbbb…/x.sol" contains an unsafe path segment "bbbb…": segment is 129 characters long (maximum 128)
workspace patch excluded file path "lib/@scope/x.sol" contains an unsafe path segment "@scope": segment contains disallowed character "@" (allowed: A-Z, a-z, 0-9, ".", "_", "-")

Lengths are counted in code points, matching the u-flag regex.

What does not change

Context

#987's real-world trigger was a 130-character Claude session directory written into the agent worktree. That came from a reverted local change (see the #986 close-out) and does not occur on main. What remains is the poor diagnostic when a legitimate target path hits the cap or the character set, which this fixes.

Test plan

  • pnpm --filter @ultrafuzz/artifacts test: 353 pass, including a new test for the 128/129 boundary, a disallowed @, and a space
  • pnpm --filter @ultrafuzz/artifacts schema:check
  • prettier --check and eslint on changed files
  • No runtime tests match on this error text

Closes #987

🤖 Generated with Claude Code

RetriggerConfidence Score: 5/5

The PR appears safe to merge.

Summary

The PR makes unsafe workspace patch path errors identify the rejected path, segment, and reason without changing validation. Tests cover the segment-length boundary and disallowed characters.

Reviews (2) · Last reviewed commit: "fix(artifacts): satisfy strict lint in p..."

… paths

normalizeWorkspacePatchPath rejected a path with only "contains an unsafe
path segment", naming neither the path, the segment, nor why. A segment
over the 128-character cap and one with a disallowed character looked
identical, which made failures expensive to diagnose.

The error now includes the path, the offending segment, and the reason:
its length against the maximum, or the first disallowed character and
the allowed set. Validation is unchanged. The 128-character bound stays
because it is part of the published ultrafuzz.workspace-patch.v1 schema;
a comment now says so.

Closes #987

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@mrthankyou
mrthankyou requested a review from a team as a code owner September 25, 2026 22:46
Count code points with a u-flag match instead of spreading the string,
and stringify numbers explicitly in the template literal.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

WORKSPACE_PATCH_SEGMENT's 128-character cap makes workspace patches fail based on how deep the run directory sits

1 participant