GitHub user Xiao-zhen-Liu edited a comment on the discussion: Design and merge plan: operator output port result cache (MVP)
**Does the cache need a new operator state?** In the #6729 review, @Yicong-Huang asked whether the CACHE_REUSED state that PR introduced needs to exist at all. Answering here since it is a design decision rather than a PR detail. It does not. The state was never the goal, only a means: the goal is showing the user which operators and ports were reused, and nobody disagrees with that. The question is only how to carry that information. A state is the wrong carrier. Checking every consumer: nothing behaves differently for a reused operator than for a completed one, and every place that checks state expects a finished operator to be COMPLETED: - Workflow level: the completion and recovery checks (ExecutionRuntimeService, ClusterListener, WorkflowService, and the ComputingUnitMaster restart sweep flagged in the review). - Operator level: the sync API's target-ready check, the reconfiguration lock, and the result panel's finished flag. So a reused operator reports COMPLETED, and the reuse information travels as one boolean: - `reused_from_cache` on OperatorMetrics, carried by the existing stats event to the frontend. The producer lands with #5884. - The UI keeps the distinction (#5886): the badge and port marks render from the flag and the cache entries. The badge can even show completed and reused together. - Counts: real numbers from operator_port_cache.tuple_count for cached output ports (#5967 kept it for this). #6729 is reworked down to exactly this: the flag and the code that carries it, 6 files. The diff there is the concrete proposal. GitHub link: https://github.com/apache/texera/discussions/5880#discussioncomment-17971744 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
