Lucio Lelii
7cabf6aa08
The assistant's validate step only ran jakarta bean-validation on FlowCreateRequest, which cascades into FlowDataValidator (the @ValidFlowStructure constraint on FlowData) but never into each block's own specificConfiguration - Block.specificConfiguration has no @Valid annotation. So per-block constraints (BranchRejoinBlockConfiguration's 2-10 input bound, LLMBlockConfiguration's placeholder-name regex, MCP shared-session producer/consumer wiring, container subflow rules via the execution-level checks, ...) were never actually enforced: the assistant could emit a structurally-broken block and still report valid=true. - FlowAssistantService.validate() now also runs FlowExecutionValidator.collectErrors(), merging its errors with the existing bean-validation errors so the repair loop sees (and can fix) what used to slip through silently. - Default max repair attempts raised from 1 to 2 (still capped at the existing max of 3), since a single fix round often isn't enough once more error classes are actually being caught. - Fixed draftDoesNotFailWhenSharedMemoryFlagsAreIncomplete: its flow was already broken (two MCP consumer-only blocks referencing a shared session neither produces) and is now correctly reported invalid instead of a false-positive valid=true. - Added two regression tests locking in the new coverage and the new default repair budget. |
||
|---|---|---|
| .mvn/wrapper | ||
| src | ||
| .gitattributes | ||
| .gitignore | ||
| Dockerfile | ||
| mvnw | ||
| mvnw.cmd | ||
| ollama-preloaded-docker | ||
| pom.xml | ||