Skip to content

CooperativeExec incorrectly implements maintains_input_order #16994

Closed

Description

@pepijnve

Describe the bug

CooperativeExec implements maintains_input_order by delegating to its input. As a consequence it may return a Vec with a length that is smaller or larger than the number of children of CooperativeExec which is always exactly 1.

To Reproduce

No response

Expected behavior

No response

Additional context

No response

Activity

  1. added a commit that references this issue on Jul 31, 2025
  2. pepijnve commented on Jul 31, 2025

    @pepijnve
    ContributorAuthor

    I came up with this as unit test, but that pretty much duplicates the implementation. Should I add this test case or is it not worth it?

    What might be useful is to have more general test logic that takes in an ExecutionPlan and verifies (to the extent possible) that the post conditions required by the trait are met. For instance that the length of the various Vecs is correct. This can't check for correctness of the values (i.e. true or false in this case), but it can check for wellformedness of the result.

    #[test]
    fn maintains_input_order() -> Result<()> {
        let schema = Arc::new(Schema::empty());
        let exec = LazyMemoryExec::try_new(schema, vec![])?;
        let coop = CooperativeExec::new(Arc::new(exec));
        let maintains_input_order = coop.maintains_input_order();
        assert_eq!(maintains_input_order, vec![true;coop.children().len()]);
        Ok(())
    }
    
  3. added
    regressionSomething that used to work no longer does
    on Jul 31, 2025
  4. alamb commented on Jul 31, 2025

    @alamb
    Contributor

    What might be useful is to have more general test logic that takes in an ExecutionPlan and verifies (to the extent possible) that the post conditions required by the trait are met. For instance that the length of the various Vecs is correct. This can't check for correctness of the values (i.e. true or false in this case), but it can check for wellformedness of the result.

    @wiedld started adding something like this with the ExecutionPlan::check_invariants:

    https://docs.rs/datafusion/latest/datafusion/physical_plan/trait.ExecutionPlan.html#method.check_invariants

    Maybe we can use that mechanism?

  5. added 3 commits that reference this issue on Aug 1, 2025
  6. added a commit that references this issue on Aug 4, 2025
  7. added a commit that references this issue on Aug 7, 2025
  8. added a commit that references this issue on Aug 7, 2025
  9. added a commit that references this issue on Aug 11, 2025
  10. added a commit that references this issue on Aug 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingregressionSomething that used to work no longer does

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions