Xiao-zhen-Liu commented on PR #5966: URL: https://github.com/apache/texera/pull/5966#issuecomment-4835180425
@Yicong-Huang on your two questions: **1. How will the cache key be used, and does the test reflect that?** The key identifies the computation behind an output port, so a re-run can decide whether to reuse the port's saved result. The cache service (#5885) stores a row keyed by the cache key when a port's result is materialized, and on a re-run computes the current key, looks it up, and on a hit confirms with `isSameComputation` (full-JSON compare) before reusing the stored result instead of recomputing. The unit tests reflect exactly that matching behavior: the same sub-DAG produces the same key (a re-run reuses), any upstream change produces a different key (it recomputes, never reusing a stale result), only upstream operators affect the key, and `isSameComputation` rejects a fabricated hash collision via the full JSON. The DB store/lookup wiring itself is exercised in #5885, where the consumer lives — this PR is just the pure key function. **2. Why did coverage say 0%?** It was a cross-module artifact: coverage is measured per module (JaCoCo), `CacheKeyUtil` is in workflow-core, but the test had been in the amber module — so the code ran but the coverage was attributed to amber, leaving the workflow-core patch at 0%. I moved the test into workflow-core (it builds `PhysicalPlan`s directly, no engine helpers), so it's now covered in its own module — patch coverage is 95.8%. -- 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]
