Fix data flow checking.

[Shylock-Hg]

What type of PR is this?

• bug
• feature
• enhancement

What problem(s) does this PR solve?

Issue(s) number:

Description:

Thie happens when I try to push filter down to AppendVertices, the ldbc query(as below) report broken promise error when I add this rule. After debugging, I found it's caused by mistake of checkDataFlow:

1. AppendVertices read by Argument operator and Argument doesn't depend on it.
2. In this case, checkDataFlow should return failure, but don't for the empty dependencies of Argument operator.
3. Then after applying this optimize rule, the origin readby relationship is erased, and new readby relationship is rebuild by dependencies relationship. But as said before, Argument operator don't depends on AppendVertices, so now Argument don't read AppendVertices too!
4. Scheduler will set dependencies of Argument by read by relationship, but now Argument lost these, so lead to broken promise error.

      MATCH
        (tagClass1:TagClass)<-[:HAS_TYPE]-(:`Tag`)<-[:HAS_TAG]-
        (forum1:Forum)-[:HAS_MEMBER]->(stranger:Person)
      WHERE id(tagClass1)=="MusicalArtist"
      WITH DISTINCT stranger
      MATCH
        (tagClass2:TagClass)<-[:HAS_TYPE]-(:`Tag`)<-[:HAS_TAG]-
        (forum2:Forum)-[:HAS_MEMBER]->(stranger)
      WHERE id(tagClass2)=="OfficeHolder"
      WITH DISTINCT stranger
      MATCH
        (person:Person)<-[:HAS_CREATOR]-(`comment`:`Comment`)-[:REPLY_OF*]->(message:Message)-[:HAS_CREATOR]->(stranger)
      WHERE person.Person.birthday > 19890101 AND
            person <> stranger
      OPTIONAL MATCH p1 = (person)-[:KNOWS]-(stranger)
      OPTIONAL MATCH p2       =(message)-[:REPLY_OF*]->(:Message)-[:HAS_CREATOR]->(stranger)
      WITH person.Person.id AS personId, stranger.Person.id AS strangerId, `comment`.`Comment`.length AS commentLength, p1, p2
      WHERE p1 IS NULL AND
            p2 IS NULL
      RETURN
        personId,
        count(DISTINCT strangerId) AS strangersCount,
        count(commentLength) AS interactionCount
      ORDER BY
        interactionCount DESC,
        personId ASC
      LIMIT 100

How do you solve it?

Special notes for your reviewer, ex. impact of this fix, design document, etc:

Checklist:

Tests:

• Unit test(positive and negative cases)
• Function test
• Performance test
• N/A

Affects:

• Documentation affected (Please add the label if documentation needs to be modified.)
• Incompatibility (If it breaks the compatibility, please describe it and add the label.）
• If it's needed to cherry-pick (If cherry-pick to some branches is required, please label the destination version(s).)
• Performance impacted: Consumes more CPU/Memory

Release notes:

Please confirm whether to be reflected in release notes and how to describe:

ex. Fixed the bug .....

[yixinglu]

Then after applying this optimize rule, the origin readby relationship is erased,

I want to know why to erase the readby relationship?

[Shylock-Hg]

Then after applying this optimize rule, the origin readby relationship is erased,

I want to know why to erase the readby relationship?

I'm not sure, it's code in OptGroup::explore. Maybe because readBy is incorrect after transforming (PlanNode is cloned).

[yixinglu]

I don't remember why to add this check here. Maybe we should find the root cause later. At present, LGTM.

[Shylock-Hg]

I don't remember why to add this check here. Maybe we should find the root cause later. At present, LGTM.

As I known, it's aimed to keep input/output relationship is subset of dependencies relationship.