Intermittent error in fillet() operation.

[yeroca]

I can't explain this. Sometimes when I load the model whose code is contained in this issue, I get a BadRequest error "Fillet failed". Usually if I exit the zoo modelling app then restart it, the problem goes away. However, switching to another kcl file and back again doesn't fix it.

Core Dump

coredump-c8536b8d-1f66-448e-a5cc-bf1ff207d033.json

Reference ID: c8536b8d-1f66-448e-a5cc-bf1ff207d033

KCL Code

holeFudge = 0.4
frontBarD = 5.0
yBarD = 6.7
slideGap = 0.7
lowerBlockTransHoleD = frontBarD + slideGap + holeFudge
lowerBlockTransHoleR = lowerBlockTransHoleD / 2
upperBlockLongHoleD = yBarD + holeFudge
upperBlockLongHoleR = upperBlockLongHoleD / 2
upperBlockTransHoleD = yBarD + holeFudge
upperBlockTransHoleR = upperBlockTransHoleD / 2
tubeClr = 1.5
lowerBlockH = lowerBlockTransHoleD + 2 * tubeClr
upperBlockH = upperBlockLongHoleD + 2 * tubeClr
elevateH = 5
upperBlockL = 25
lowerBlockL = 70
blockSz = max(upperBlockH, lowerBlockH)

slotL = 10
slotH = 1

fn slot () {
  slotSketch = startSketchOn('XZ')
    |> startProfileAt([0, -(blockSz - slotH) / 2], %)
    |> xLine(slotL, %)
    |> yLine(-slotH, %)
    |> xLine(-slotL, %)
    |> close(%)
  return slotSketch
}
sketch001 = startSketchOn('XZ')
  |> startProfileAt([0, 0], %)
  |> yLine(blockSz, %, $edgeA)
  |> xLine(blockSz, %, $edgeB)
  |> yLine(-blockSz, %, $edgeC)
  |> xLine(upperBlockL - blockSz, %, $edge1)
  |> yLine(-(elevateH + blockSz), %, $edge2)
  |> xLine(lowerBlockL - blockSz, %, $edge3)
  |> yLine(-blockSz, %, $edge4)
  |> xLine(-lowerBlockL, %, $edge5)
  |> yLine(blockSz + elevateH, %, $edge6)
  |> xLine(-(upperBlockL - blockSz), %, $edge7)
  |> lineTo([profileStartX(%), profileStartY(%)], %, $seg01)
  |> close(%)
  // |> hole(slot(), %)
  |> hole(circle({
       center = [blockSz / 2, blockSz / 2],
       radius = upperBlockTransHoleR
     }, %), %)
  |> hole(circle({
       center = [
         upperBlockL + lowerBlockL - blockSz - lowerBlockTransHoleR - tubeClr,
         -(blockSz + elevateH + blockSz / 2)
       ],
       radius = lowerBlockTransHoleR
     }, %), %)
rad = 3
extrude001 = extrude(blockSz, sketch001)
  |> fillet({
       radius = rad,
       tags = [
       getNextAdjacentEdge(edgeA),
          getNextAdjacentEdge(edgeB),
          getNextAdjacentEdge(edgeC),
          getNextAdjacentEdge(edge2),
          getNextAdjacentEdge(edge3),
          getNextAdjacentEdge(edge4),
          getNextAdjacentEdge(edge5),
          getNextAdjacentEdge(edge6)
       ]
     }, %)

sketch006 = startSketchOn(extrude001, 'START')
  |> startProfileAt([-25, 0], %)
  |> xLine(upperBlockL, %)
  |> yLine(-upperBlockH, %)
  |> xLine(-upperBlockL, %)
  |> lineTo([profileStartX(%), profileStartY(%)], %)
  |> close(%)

sketch007 = startSketchOn(extrude001, 'END')
  |> startProfileAt([0, 0], %)
  |> xLine(upperBlockL, %)
  |> yLine(-upperBlockH, %)
  |> xLine(-upperBlockL, %)
  |> lineTo([profileStartX(%), profileStartY(%)], %)
  |> close(%)

frontFaceOff = blockSz
backFaceOff = 0
bevel = 3
plane1 = offsetPlane('XZ', frontFaceOff + bevel)
sketch010 = startSketchOn(plane1)
  |> startProfileAt([0, -bevel], %)
  |> xLine(upperBlockL, %)
  |> yLine(-(upperBlockH - (2 * bevel)), %)
  |> xLine(-upperBlockL, %)
  |> lineTo([profileStartX(%), profileStartY(%)], %)
  |> close(%)
loft001 = loft([sketch007, sketch010])

sketch008 = startSketchOn('XZ')
  |> startProfileAt([0, 0], %)
  |> xLine(upperBlockL, %)
  |> yLine(-upperBlockH, %)
  |> xLine(-upperBlockL, %)
  |> lineTo([profileStartX(%), profileStartY(%)], %)
  |> close(%)
plane2 = offsetPlane('XZ', -bevel)
sketch011 = startSketchOn(plane2)
  |> startProfileAt([0, -bevel], %)
  |> xLine(upperBlockL, %)
  |> yLine(-(upperBlockH - (2 * bevel)), %)
  |> xLine(-upperBlockL, %)
  |> lineTo([profileStartX(%), profileStartY(%)], %)
  |> close(%)
loft002 = loft([sketch008, sketch011])

sketch002 = startSketchOn(extrude001, seg01)
  |> startProfileAt([0, 0], %)
  |> circle({
       center = [blockSz / 2, -blockSz / 2],
       radius = upperBlockLongHoleR
     }, %)
extrude2 = extrude(-upperBlockL, sketch002)

[yeroca]

I'm seeing this reproduceably. I have three small kcl files in the directory. When I open the zoo app, it seems to auto-select the first file sorted alphabetically, which is this "extended_front_tube_elbow.kcl" file. In this case, it opens and doesn't have a problem with the fillet operation. But if I then switch to the second file in the list, and then back to the "extended_..." file, I get the fillet error.

Just in case it makes a difference, I'm attaching the other file I switched to.

switch_protector.kcl.txt

[jessfraz]

@franknoirot iirc the last time this was happening reliably it meant the models were executing twice on load and over one another, could this be another race? or instance where models execute twice thru different code paths

[franknoirot]

Really rich context provided here thank you so much @yeroca.

It's possible @jessfraz! My other two hypotheses are execution cache and engine fillet instability which has been documented elsewhere. We'll try to tease it apart

[Irev-Dev]

@jtran Could this have been fixed by the non-deterministic execution behaviour you fixed recently?

[jtran]

I don't think so. The non-determinism only affected chamfer. And only since its keyword args conversion, Feb 21.

• Fix to have deterministic order of commands #5583

[yeroca]

I don't know if this helps, but I notice that when this error occurs, eliminating certain edges from the fillet call makes the error go away.

So my guess is that it's an error in associating the tagged edge to the vertex that is supposed to be filleted. It gives the gut feel of some kind of off-by-one error, perhaps due to an uninitialized variable or something.

Another reason I think this is that after removing the “offending” edges from the fillet, some of the remaining fillets are now in the wrong places. In other words, some of the edges where I didn't want a fillet received a fillet, and vice versa.

[nadr0]

I am converting the original KCL code to the latest version of our KCL language. I am at the first fillet call and I am concerned because we do not have this support for fillet.

  |> fillet({
       radius = rad,
       tags = [
         getNextAdjacentEdge(edgeA), <-- adjacent to B
          getNextAdjacentEdge(edgeB), <-- adjacent to C
          getNextAdjacentEdge(edgeC),
          getNextAdjacentEdge(edge2),
          getNextAdjacentEdge(edge3),
          getNextAdjacentEdge(edge4),
          getNextAdjacentEdge(edge5),
          getNextAdjacentEdge(edge6)
       ]
     }, %)

These adjacent edges will fail we do not have the ability to fillet edges that are next to one another right now.

I cannot continue to debug this since the original KCL code has fillet logic we do not support. I do not know how to recreate the original fillet issue with this code.

Update: hmm I see this is actually correct but the fillets are failing. Going to try and debug. This code should actually be every other edge instead of adjacent edges

@settings(defaultLengthUnit = mm, defaultAngleUnit = deg)

holeFudge = 0.4
frontBarD = 5.0
yBarD = 6.7
slideGap = 0.7
lowerBlockTransHoleD = frontBarD + slideGap + holeFudge
lowerBlockTransHoleR = lowerBlockTransHoleD / 2
upperBlockLongHoleD = yBarD + holeFudge
upperBlockLongHoleR = upperBlockLongHoleD / 2
upperBlockTransHoleD = yBarD + holeFudge
upperBlockTransHoleR = upperBlockTransHoleD / 2
tubeClr = 1.5
lowerBlockH = lowerBlockTransHoleD + 2 * tubeClr
upperBlockH = upperBlockLongHoleD + 2 * tubeClr
elevateH = 5
upperBlockL = 25
lowerBlockL = 70
blockSz = max(upperBlockH, lowerBlockH)

slotL = 10
slotH = 1

fn slot() {
  slotSketch = startSketchOn(XZ)
    |> startProfileAt([0, -(blockSz - slotH) / 2], %)
    |> xLine(length = slotL)
    |> yLine(length = -slotH)
    |> xLine(length = -slotL)
    |> close(%)
  return slotSketch
}
sketch001 = startSketchOn(XZ)
  |> startProfileAt([0, 0], %)
  |> yLine(length = blockSz, tag = $edgeA)
  |> xLine(length = blockSz, tag = $edgeB)
  |> yLine(length = -blockSz, tag = $edgeC)
  |> xLine(length = upperBlockL - blockSz, tag = $edge1)
  |> yLine(length = -(elevateH + blockSz), tag = $edge2)
  |> xLine(length = lowerBlockL - blockSz, tag = $edge3)
  |> yLine(length = -blockSz, tag = $edge4)
  |> xLine(length = -lowerBlockL, tag = $edge5)
  |> yLine(length = blockSz + elevateH, tag = $edge6)
  |> xLine(length = -(upperBlockL - blockSz), tag = $edge7)
  |> line(endAbsolute = [profileStartX(%), profileStartY(%)], tag = $seg01)
  |> close(%)
  |> hole(circle(center = [blockSz / 2, blockSz / 2], radius = upperBlockTransHoleR), %)
  |> hole(circle(
       center = [
         upperBlockL + lowerBlockL - blockSz - lowerBlockTransHoleR - tubeClr,
         -(blockSz + elevateH + blockSz / 2)
       ],
       radius = lowerBlockTransHoleR,
     ), %)

rad = 3
extrude001 = extrude(sketch001, length = blockSz)

[yeroca]

Hi Kevin,

I have been keeping the code up on my side with the latest KCL changes. Right now, the behavior is still very weird, even though I'm not seeing a (reproducible) error at the moment, it's still putting fillets on different edges when I first load the model, versus when I switch to another model and back again.

In addition, there's a hole I've defined in upper block that is performed with a negative extrusion, and if I comment out the last fillet in the list, the hole moves to the side for some reason. Perhaps the plane is redefined somehow.

Here's the current code I'm using:

holeFudge = 0.4
frontBarD = 5.0
yBarD = 6.7
slideGap = 0.7
lowerBlockTransHole = {
r = (frontBarD + slideGap + holeFudge) / 2
}
upperBlockLongHole = { r = (yBarD + holeFudge) / 2 }

upperBlockTransHole = { r = (yBarD + holeFudge) / 2 }
tubeClr = 1.5
lowerBlock = {
h = 2 * lowerBlockTransHole.r + 2 * tubeClr,
l = 70
}
upperBlock = {
h = 2 * upperBlockLongHole.r + 2 * tubeClr,
l = 25
}
elevate = { h = 5 }

blockSz = max(upperBlock.h, lowerBlock.h)

slot = { l = 10, h = 1 }

sketch001 = startSketchOn(XZ)
|> startProfileAt([0, 0], %)
|> yLine(length = blockSz, tag = $edgeA)
|> xLine(length = blockSz, tag = $edgeB)
|> yLine(length = -blockSz, tag = $edgeC)
|> xLine(length = upperBlock.l - blockSz, tag = $edge1)
|> yLine(length = -(elevate.h + blockSz), tag = $edge2)
|> xLine(length = lowerBlock.l - blockSz, tag = $edge3)
|> yLine(length = -blockSz, tag = $edge4)
|> xLine(length = -lowerBlock.l, tag = $edge5)
|> yLine(length = blockSz + elevate.h, tag = $edge6)
|> xLine(length = -(upperBlock.l - blockSz), tag = $edge7)
|> line(endAbsolute = [profileStartX(%), profileStartY(%)], tag = $seg01)
|> close(%)
|> hole(circle(center = [blockSz / 2, blockSz / 2], radius = upperBlockTransHole.r), %)
|> hole(circle(
center = [
upperBlock.l + lowerBlock.l - blockSz - lowerBlockTransHole.r - tubeClr,
-(blockSz + elevate.h + blockSz / 2)
],
radius = lowerBlockTransHole.r,
), %)
rad = 3

extrude001 = extrude(sketch001, length = blockSz)

|> fillet(
radius = rad,
tags = [
//getNextAdjacentEdge(edgeA),
getNextAdjacentEdge(edgeB),
getNextAdjacentEdge(edgeC),
getNextAdjacentEdge(edge1),
getNextAdjacentEdge(edge2),
getNextAdjacentEdge(edge3),
getNextAdjacentEdge(edge4),
getNextAdjacentEdge(edge5),
getNextAdjacentEdge(edge6),
getNextAdjacentEdge(edge7)
],
)

sketch002 = startSketchOn(extrude001, seg01)
|> startProfileAt([0, 0], %)
|> circle(center = [blockSz / 2, -blockSz / 2], radius = upperBlockLongHole.r)
|> extrude(length = -upperBlock.l)

Here's what it looks like when it's correct:

Here's what it looks like when it's first loaded:

Here's what it looks like when I switch to the "switch_protector.kcl" model, and then switch back again, then comment out getNextAdjacentEdge(edge7);

All quite weird.

By the way, in case it matters, I've updated switch_protector.kcl as well:

holeFudgeD = 0.4
holeFudgeR = holeFudgeD / 2

totalH = 12.5
switchNutD = 9.5
switchNutR = switchNutD / 2
bottomInnerR = switchNutR + holeFudgeR
bottomOuterR = 13.5
topInnerR = switchNutR + 1.5 + holeFudgeR
topFlatL = 1
topOuterR = topInnerR + topFlatL
baseH = 1
coneH = totalH - baseH

sketch001 = startSketchOn(XZ)
|> startProfileAt([bottomInnerR, 0], %)
|> xLine(endAbsolute = bottomOuterR)
|> yLine(length = baseH)
|> line(end = [-(bottomOuterR - topOuterR), coneH])
|> line(end = [-(topOuterR - topInnerR), 0])
|> close(%)
|> revolve(axis = 'Y')

[nadr0]

2025-03-28.10-21-52.mp4

I appreciate the response and the updated KCL code that is useful. I am unable to fillet any single edge. We have a fillet ticket that keeps track of many fillet issues. I am going to put this ticket into that bucket of issues.

I am confused how your modeling application and produce the fillet edges but when I run the same v0.51.0 application it cannot fillet any of the edges?

@franknoirot Can you try this out with yeroca's latest code?

Update: I went down a massive fillet rabbit hole. Turns out the project units were determining the default tolerance on the fillets. All of mine failed due to the tolerance being too big 10e-3. I can now test this code again. I'll need to manually set a larger tolerance. Jon is making a fix for this tolerance issue.

Context

tolerance on the fillet is be defaulted to difficult values in different environments causing it to fail because the tolerance is not small enough.
extrude001 = extrude(profile001, length = 100) |> fillet(%, radius = 2.0, tags = [rectangleSegmentA001])
^--- has no defined tolerance so it will need a default.
./zoo kcl export ~/Documents/test.kcl --output-format ply .
^-- tolerance of 1e-7
Zoo cli export: 1e-7
Firefox: 1e-3
Chrome: 1e-7
Production v0.51.0 release: 1e-3
yarn tron:start: 1e-3

[jessfraz]

I still think its executing over itself its the only reason in my mind could be wrong why its non-deterministic otherwise we'd see fillet code fail randomly in the rust ci, which does happen when real fillet bugs in engine occur

[jessfraz]

like let me run this code over and over again w raw rust no js and i bet its fine

[jessfraz]

so far so good :) my money is on js racesssss

[jessfraz]

it would be VERY VERY good to get to the bottom of these before v1, also just wasteful compute if we are executing over ourselves

[jessfraz]

its 100% deterministically working fine in rust, i removed the engine label this is not their issue

[jtran]

@jessfraz, the CLI script proves it's a state problem. But it doesn't prove much else. Let me explain.

First, I reproduced the problem locally. It's 100% deterministic. I can trigger it every time.

1. Open main.kcl. This works.
2. Switch to switch_protector.kcl
3. Switch back to main.kcl. This is broken.

Curiously, I noticed that to reproduce the problem I do indeed need switch_protector.kcl, not just switching to any other file. I tried switching to a blank file and a cube file. Neither of those caused the problem.

I commented out the final revolve() from switch_protector.kcl, and the problem went away. So I made a minimal trigger file called rev.kcl that has a square sketch and a revolve only.

Then I tried to simplify main file in min_failing.kcl. I simplified some, but it's annoying.

I decided to take a different approach and compare the WebSocket messages in the successful run with the failing run. The WebSocket messages are the ultimate authority on which side the problem is on. See har.json.

Comparing them was significantly easier thanks to the recent change to deterministic UUIDs, so thanks for that! Engine response maps still come back in random order, and the fillet edge UUID that eventually fails is different, but it maps to the same thing. As far as I can tell, from the make_plane request up to the failed fillet response, messages to the engine are logically identical.

So I'm throwing this sucker back in engine's court!

Files that I used are attached.

fillet-issue-4797.zip

[jtran]

Basically, for a proper CLI proof, I'd want it to see:

1. Run the original KCL
2. Run the triggering rev.kcl to simulate switching files
3. Then run the original file again, all without closing the engine connection

[davreev]

Update on this here. Any thoughts on why calling getNextAdjacentEdge on an edge tag might have the effect we're seeing here?

[Irev-Dev]

if getNextAdjacentEdge is causing an issue, than https://github.com/KittyCAD/engine/issues/3244 would fix this.

But it's probably revealing a bug that should be fixed because I don't think we want getNextAdjacentEdge causing an issue like this.

[franknoirot]

@jtran will rebase #6155 and see if it's been fixed

[jtran]

I rebased it here, and as far as I can tell, this is still failing.

• test to repro fillet failed error #6719

[yeroca]

Updated code to v1.0.1:

holeFudge = 0.4
frontBarD = 5.0
yBarD = 6.7
slideGap = 0.7
lowerBlockTransHole = {
  r = (frontBarD + slideGap + holeFudge) / 2
}
upperBlockLongHole = { r = (yBarD + holeFudge) / 2 }

upperBlockTransHole = { r = (yBarD + holeFudge) / 2 }
tubeClr = 1.5
lowerBlock = {
  h = 2 * lowerBlockTransHole.r + 2 * tubeClr,
  l = 70
}
upperBlock = {
  h = 2 * upperBlockLongHole.r + 2 * tubeClr,
  l = 25
}
elevate = { h = 5 }

blockSz = max([upperBlock.h, lowerBlock.h])

slot = { l = 10, h = 1 }

baseSideProfile = startSketchOn(XZ)
  |> startProfile(at = [0, 0])
  |> yLine(length = blockSz, tag = $edgeA)
  |> xLine(length = blockSz, tag = $edgeB)
  |> yLine(length = -blockSz, tag = $edgeC)
  |> xLine(length = upperBlock.l - blockSz, tag = $edge1)
  |> yLine(length = -(elevate.h + blockSz), tag = $edge2)
  |> xLine(length = lowerBlock.l - blockSz, tag = $edge3)
  |> yLine(length = -blockSz, tag = $edge4)
  |> xLine(length = -lowerBlock.l, tag = $edge5)
  |> yLine(length = blockSz + elevate.h, tag = $edge6)
  |> xLine(length = -(upperBlock.l - blockSz), tag = $edge7)
  |> line(endAbsolute = [profileStartX(%), profileStartY(%)], tag = $seg01)
  |> close()

lowerSideHole = startSketchOn(XZ)
  |> circle(center = [blockSz / 2, blockSz / 2], radius = upperBlockTransHole.r)

upperSideHole = startSketchOn(XZ)
  |> circle(
       center = [
         upperBlock.l + lowerBlock.l - blockSz - lowerBlockTransHole.r - tubeClr,
         -(blockSz + elevate.h + blockSz / 2)
       ],
       radius = lowerBlockTransHole.r,
     )

sideProfile = subtract2d(baseSideProfile, tool = [lowerSideHole, upperSideHole])

rad = 3

extrude001 = extrude(sideProfile, length = blockSz)
|> fillet(
       radius = rad,
       tags = [
         // getNextAdjacentEdge(edgeA),
         getNextAdjacentEdge(edgeB),
         getNextAdjacentEdge(edgeC),
         //getNextAdjacentEdge(edge1),
         getNextAdjacentEdge(edge2),
         getNextAdjacentEdge(edge3),
         getNextAdjacentEdge(edge4),
         getNextAdjacentEdge(edge5),
         getNextAdjacentEdge(edge6),
         //getNextAdjacentEdge(edge7)
       ],
     )

yBarHole = startSketchOn(YZ)
  |> startProfile(at = [0, 0])
  |> circle(center = [-blockSz / 2, -blockSz / 2], radius = upperBlockLongHole.r)
  |> extrude(length = upperBlock.l)

subtract(extrude001, tools = [yBarHole])

holeFudgeD = 0.4
holeFudgeR = holeFudgeD / 2

totalH = 12.5
switchNutD = 9.5
switchNutR = switchNutD / 2
bottomInnerR = switchNutR + holeFudgeR
bottomOuterR = 13.5
topInnerR = switchNutR + 1.5 + holeFudgeR
topFlatL = 1
topOuterR = topInnerR + topFlatL
baseH = 1
coneH = totalH - baseH

sketch001 = startSketchOn(XZ)
  |> startProfile(at = [bottomInnerR, 0])
  |> xLine(endAbsolute = bottomOuterR)
  |> yLine(length = baseH)
  |> line(end = [-(bottomOuterR - topOuterR), coneH])
  |> line(end = [-(topOuterR - topInnerR), 0])
  |> close(%)
  |> revolve(axis = Y)

[jtran]

@yeroca, thank you for your patience here.

This has been a particularly tricky bug to figure out, but we haven't given up. We think we've narrowed this down to revolve(). It can be in the same file or even in another file that you switch between. It causes next and previous adjacent edges to flip. So your fillet is actually incorrectly trying to fillet the edge on the opposite side of the intended face. I believe a workaround is to avoid 360 degree revolve(). Up to 359.9 degrees may work.

[yeroca]

@yeroca, thank you for your patience here.

This has been a particularly tricky bug to figure out, but we haven't given up. We think we've narrowed this down to revolve(). It can be in the same file or even in another file that you switch between. It causes next and previous adjacent edges to flip. So your fillet is actually incorrectly trying to fillet the edge on the opposite side of the intended face. I believe a workaround is to avoid 360 degree revolve(). Up to 359.9 degrees may work.

Thanks for the note! Interestingly the only other two other files in this project both had revolve in them, so switching to either of those files caused the error to occur when I switched back again. Adding angle = 359.9 fixed it.

Both the fact that this occurs only a full rotate (which is the default), and that there is cross interaction between files is interesting, but the latter problem seems the most worrisome to me.