Re: [D] Design and merge plan: operator output port result cache (MVP) [texera]

["Xiao-zhen-Liu (via GitHub)" <gi...@apache.org>]

GitHub user Xiao-zhen-Liu added a comment to the discussion: Design and merge plan: operator output port result cache (MVP)

Agreed. One clarification first: CACHE_REUSED 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. I checked 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 you found).
- 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 dev@texera.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@texera.apache.org