The GitHub Actions job "Required Checks" on texera.git/gh-readonly-queue/main/pr-6143-42f9d0e90e15e13acc420b70d4f635f30d3e832c has succeeded. Run started by GitHub user Yicong-Huang (triggered by Yicong-Huang).
Head commit for run: a7989ee78e27ab7b909bdf8aaed586a5f030528c / Yicong Huang <[email protected]> refactor(workflow-compiler): unify duplicate compilers into common/workflow-compiler (#6143) ### What changes were proposed in this PR? **This is a source-level de-duplication only — the runtime behavior of two compilations stays.** A workflow is still compiled twice: once at editing time (through workflow-compiling-service) and once at execution time (through amber). This PR only makes both paths share one compiler implementation instead of two hand-synced copies. amber and workflow-compiling-service each maintained a separate copy of the workflow compiler and its models (`WorkflowCompiler`, `LogicalPlan`, `LogicalLink`, `LogicalPlanPojo`), which had to be kept in sync by hand (e.g. #6288 had to patch both copies). This PR consolidates them into a single shared `common/workflow-compiler` module that both services depend on; the old per-service copies are removed. The unified `WorkflowCompiler.compile` returns a `WorkflowCompilationResult` (logical plan, optional physical plan, per-port output schemas, per-operator errors, and the output ports needing storage) and takes a `CompilationErrorHandling` mode: `Lenient` for the editing-time path (accumulate per-operator errors so the UI can render them) and `Strict` for the execution path (fail-fast before a run). amber's engine `Workflow` becomes a thin wrapper over the compilation result, built via `Workflow.fromCompilationResult`. Two known minor behavior changes (both flagged in review, both intentional): - Plan expansion now uses `scala.util.Try` (non-fatal only) where the old compiling-service caught `Throwable`, so a fatal JVM error during expansion now fails the `/compile` request instead of being recorded per-operator. - `Strict` now also fails fast on schema-propagation errors (e.g. a Projection on a missing column). The legacy execution path silently launched such plans and they only failed at runtime; per review discussion the fail-fast contract now covers this case too, pinned by a test. ### Any related issues, documentation, discussions? Closes #6142. Design rationale lives in the scaladoc of `WorkflowCompiler`. ### How was this PR tested? - Migrated the compiler and model unit specs into the new module and added strict-mode coverage (success path and the schema-propagation fail-fast path). - amber and workflow-compiling-service compile and test against the shared library. - Rebased over #6288 and verified its error-message changes carry over into the shared module (they now exist in one place instead of two). ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Opus 4.8 (Claude Code); review follow-ups by Claude Fable 5 (Claude Code) --------- Co-authored-by: Claude Fable 5 <[email protected]> Report URL: https://github.com/apache/texera/actions/runs/30301992459 With regards, GitHub Actions via GitBox
