DanielLeens commented on issue #10651: URL: https://github.com/apache/seatunnel/issues/10651#issuecomment-5525512505
Thanks for grounding this in the two merged foundations. I prefer option 2: define a reusable, config-level validation-result model first, then add CLI, MCP, or REST adapters as separate consumers. Current dev already has the dry-run validation command and structured metadata export, but DryRunConnectValidator still communicates failure mainly by ConfigCheckException text; making one CLI JSON shape first would freeze a transport contract before the underlying semantics are explicit. Please keep the first slice narrow: a versioned result/error model with valid, phase, location or plugin, option path when known, rule category, and sanitized message; preserve the existing human-readable --check output and exit behavior; do not claim runtime-equivalent validation or bind an LLM provider. Focused tests should cover stable JSON serialization, human-output compatibility, and representative parse, option, and plugin-load failures. Once that model is accepted, --check --format json can be a thin adapter, while MCP or REST should remain follow-up work. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
