[jayshrivastava]

Which issue does this PR close?

• Informs [EPIC] dynamic filtering datafusion-contrib/datafusion-distributed#528.

What changes are included in this PR?

This PR adds a helper similar to DynamicFilterPhysicalExpr::update() which takes a different DynamicFilterPhysicalExpr.

pub fn update_from(&self, source: &Self) -> Result<()> {

Rationale for this change

The use case I have is that I want to update a Arc<DynamicFilterPhysicalExpr> from a different Arc<DynamicFilterPhysicalExpr> (as opposed to the normal update() API which takes a non dynamic filter Arc<dyn PhysicalExpr>).

This requires accessing private fields like Inner. Rather than exposing private fields, I thought that adding an update_from(Self) API is cleaner.

Note that you cannot call

dynamic_filter_1.update(dynamic_filter_2.current())

because
a) it doesn't copy is_complete
b) it doesn't copy inner.expr directly. current() returns the expression with remapped columns and calling dynamic_filter_expr.update(remapped_expression); dynamic_filter_expr.current() breaks because current() cannot remap the remapped expression.

Alternatives Considered

1. As a hack to get the private internal state, we currently incur a proto roundtrip, which makes fields like inner.expr and is_complete public. This is undesirable because it adds overhead
2. Replace a dynamic filter entirely rather than mutate it. Currently datafusion has no API to "replace" a dynamic filter with another one in an ExecutionPlan. In a way, this is what update_from does, taking advantage of interior mutability.

What is the testing strategy for this PR?

One unit test

Are there any user-facing changes?

No.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 85.71429% with 24 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.94%. Comparing base (63af08d) to head (9f8db33).
⚠️ Report is 36 commits behind head on main.

Files with missing lines	Patch %	Lines
...ysical-expr/src/expressions/dynamic_filters/mod.rs	85.71%	2 Missing and 22 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #26534      +/-   ##
==========================================
+ Coverage   82.91%   82.94%   +0.02%     
==========================================
  Files        1155     1156       +1     
  Lines      458058   458717     +659     
  Branches   458058   458717     +659     
==========================================
+ Hits       379813   380489     +676     
+ Misses      55202    55148      -54     
- Partials    23043    23080      +37     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[rgbuilds]

Once current.is_complete is true, consumers may stop tracking this filter because the API contract says its expression will no longer change. However, update_from can still replace the expression of an already-complete target while preserving is_complete = true.

The final step of test_update_from_notifies_waiters_and_preserves_completion appears to exercise this case: the target is complete with lit(false), then receives the incomplete snapshot containing lit(true). The target therefore remains complete but its expression changes.

Could update_from reject or ignore updates when the target is already complete? A regression assertion that the expression, generation, and watch state remain unchanged would also help protect the terminal completion contract.