The GitHub Actions job "Required Checks" on texera.git/main has failed.
Run started by GitHub user github-merge-queue[bot] (triggered by 
github-merge-queue[bot]).

Head commit for run:
2442e8f3ebd12353bd5c9cfa40873a1f980e7011 / Xiaozhen Liu <[email protected]>
feat(workflow-core): add operator output port cache key (#5966)

### What changes were proposed in this PR?

Adds `CacheKeyUtil` (in workflow-core), which computes a deterministic
cache key for
an output port from the upstream sub-DAG that produces it. The sub-DAG
is the port's
operator plus its transitive upstream, obtained from a new
`PhysicalPlan.getTransitiveUpstreamSubPlan(opId)`; `computeCacheKey`
takes that sub-DAG.
For a target output port, the key is built from:

- the target output port's identity;
- every operator in the sub-DAG and, for each: its physical and logical
operator id,
its execution init info (the concrete execution definition the engine
runs), and the
  schema of each of its output ports;
- the edges among those operators, including the specific ports each
edge connects.

These are written to a JSON document with sorted keys and a sorted
operator and edge
order, so the same upstream computation always serializes to the same
bytes and hashes
(SHA-256) to the same key. Any upstream change (a parameter edit, a
rewiring, a schema
change) produces a different key; changes elsewhere in the workflow do
not.

Matching is collision-safe: `isSameComputation` compares the hash first
and, on a hash
match, confirms with the full JSON, so a hash collision never reuses a
result the port
was not computed from.

This is the first piece of the operator output port result cache.
`CacheKeyUtil` is a
pure function with no database or storage dependency, and nothing calls
it yet, so it
changes no existing behavior. The cache table (companion PR) and the
service that uses
both land separately.

### Any related issues, documentation, discussions?

Closes #5968. Part of the storage foundation #5882 (umbrella #5881).
Design discussion: #5880.

### How was this PR tested?

New unit tests in workflow-core (built from `PhysicalPlan`s directly, no
engine test
helpers, so the logic is covered in its own module): `CacheKeyUtilSpec`
covers a stable
key, sensitivity to an upstream change, different ports, a source with
no upstream,
upstream-only scope, and the three `isSameComputation` cases; the new
`PhysicalPlan.getTransitiveUpstreamSubPlan` is tested in
`WorkflowCoreTypesSpec`. Run with
`sbt "WorkflowCore/testOnly *CacheKeyUtilSpec *WorkflowCoreTypesSpec"` —
all pass.

### Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Opus 4.8 (Claude Code)

Report URL: https://github.com/apache/texera/actions/runs/28460870034

With regards,
GitHub Actions via GitBox

Reply via email to