Bump ezpz to 0.2.28

[adamchalmers]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
modeling-app	Ready	Preview	Aug 4, 2026 10:17pm

[codspeed-hq]

Merging this PR will not alter performance

✅ 126 untouched benchmarks
⏩ 151 skipped benchmarks¹

---

_{Comparing achalmers/ezpz-27 (ba5f18e) with main (6b01bc2)²}

Footnotes

1. 151 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (02452c8) during the generation of this report, so 6b01bc2 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[davreev]

Seeing a failure on fillet_ambiguous_region_edge_specifier_broad that seems legit. Still looking into it but regions seem to be resolving differently (potentially due to slight numerical differences) which affects the extrusion and subsequent fillet.

Update: I think this is just a case of tolerances disagreeing between ezpz and toolpaths. Coordinate diffs are well within ezpz's residual_tolerance (max is ~7.14e-10) but they're large enough to cause regions to resolve differently.

[davreev]

We were getting a false positive on this one before - lines were the same before and after the solve. Ezpz changes just surfaced it.

[davreev]

Worth flagging: LinesAtAngle is prone to collapse when initial conditions are pi/2 from the target angle and the lengths of the lines aren't otherwise constrained. Planning to address this in the next ezpz release.

[davreev]

Ok I think I've gotten as far as I can with addressing cargo test failures for now. We've got 4 remaining failures that seem to be hitting a similar issue: sketches are converging on the same shape within ezpz tolerance (1e-8) but the tiny changes in coordinates are are causing downstream operations to fail/misbehave. Additional per-test details below.

Not entirely sure how to proceed from here. Seems like it could take some time to resolve these but we're effectively blocked on ezpz updates until we do.

fillet_ambiguous_region_edge_specifier/fillet_ambiguous_region_edge_specifier_broad

Sketch solves to the same shape on 0.2.28 within tolerance (max coord delta is ~7.14e-10) but regions resolve differently. Comparison of behavior on 0.2.28 (top) with behavior with 0.2.26 (bottom):

fillet-ambiguous-region-2-28.mp4

fillet-ambiguous-region-2-26.mp4

fun_stacker_toy

Sketch solves to the same shape on 0.2.28 within tolerance (with the exception of circle start anchors which differ up to 1e-4 since they're unconstrained/free to drift on the perimeter) but regions don't resolve correctly:

Related issue: https://github.com/KittyCAD/toolpaths/issues/431

sheet_metal_bracket

Sketch solves to the same shape on 0.2.28 within tolerance with the exception of a small handful of coords whose diff is between 1e-5 and 1e-6. Failure is in the downstream CSG subtract and is caused by a single extrusion (from region009) whose profile/placement doesn't appear to be problematic. Can't see why this one would fail.

[davreev]

FYI can ignore failure on error_large_fillet_radiusas it's been disabled (details: https://kittycadworkspace.slack.com/archives/C09LS6MA43H/p1784744064631649)

[davreev]

Update: fillet_ambiguous_region* and fun_stacker_toy failures were being caused by some tolerance inconsistencies in toolpaths which have been addressed. The CSG subtract failure in sheet_metal_bracket remains a mystery but updating the KCL to use warm initial values seems to be enough to get around it for now. Will add it to the list of CSG issues to investigate.

[jtran]

Please merge main to not miss new tests added.