Lucio Lelii
3d16a3b388
Answers "perché il fix non riesce a risolvere il problema?" - traced via a live repro (session log + direct save attempt) why a LoopContainer body left in a fully closed 2-block cycle (no input left open for guard feedback) never got fixed even after both repair rounds ran. Root cause: when a container-level validation error isn't attributable to any specific inner block, normalizeContainerInnerBlocksAgainstExisting force-ADDs every inner block each round (the existing "a FIX round that changes nothing would never fix the error" fallback) - even though the model marks them KEEP. But resolveExistingBlock's position-based fallback still matches the old block regardless of the forced operation, so oldInnerIdToAssembled/oldNodeIdToAssembledNode got populated anyway, and preserveConnections carried the OLD (still-broken) connections forward every round on top of whatever the fresh connections-for- container call produced. The model has no way to ask for a connection's removal, so the stale, well-formed (non-dangling) connection survived indefinitely - the previous dangling-reference fixes didn't catch this because nothing here is dangling, it's a stale-but-valid connection. Fix: only populate the old-to-new node id mapping used for connection preservation when the block/container's operation is genuinely KEEP or UPDATE, never ADD - regardless of why it became ADD (explicit model choice or the force-regen fallback). Applied consistently at all three sites (top-level blocks, top-level containers, container-inner blocks). Verified by mutation testing: reverting the container-inner guard reproduces the exact live failure (2 connections instead of 1) in the new regression test; restoring it fixes it. Full suite: 439/439. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .mvn/wrapper | ||
| src | ||
| .gitattributes | ||
| .gitignore | ||
| Dockerfile | ||
| mvnw | ||
| mvnw.cmd | ||
| ollama-preloaded-docker | ||
| pom.xml | ||