kz930 opened a new pull request, #7261: URL: https://github.com/apache/texera/pull/7261
### What changes were proposed in this pull request? `customDelimiter` on the three CSV scans is declared as a string with no length constraint, while every reader narrows it with `charAt(0)` — univocity's `setDelimiter` and scala-csv's `DefaultCSVFormat.delimiter` both take a `Char`. Each now declares `maxLength: 1`, and the description says a single character rather than leaving it implied. ### Why are the changes needed? Characters past the first are dropped without a word. Driving each operator's own `sourceSchema()` over a three-column `;`-separated file, `;abc` infers the same three columns as `;`, and `,;` collapses to one column exactly as a bare `,` does — so the second character never participates. A workflow typed that way runs to completion and looks right, and nothing ever says part of the field was discarded. ### Does this PR introduce any user-facing change? Yes, and one worth calling out. A saved workflow whose Delimiter holds more than one character will now show as invalid in the property editor, since the form validates the stored properties against the schema. It still runs — the backend does not enforce the schema — and the run behaves exactly as before, because only the first character ever counted. Surfacing those workflows is the point: today they are silently truncating. ### How was this patch tested? `WorkflowOperator/compile`, `scalafmtCheckAll`, and the three operators' descriptor specs (19 tests). Closes #7211 Generated-by: Claude Code (Claude Opus 5) -- 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]
