[This write-up on BEAM-5441](https://issues.apache.org/jira/browse/BEAM-5441?focusedCommentId=16622983&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16622983) gives the best context:
> DirectRunner [replaces a > GBK](https://github.com/apache/beam/blob/master/runners/direct-java/src/main/java/org/apache/beam/runners/direct/DirectRunner.java#L264-L266) > (normally a primitive transform) with [a wrapper for two runner-specific > transforms ("group by key only" and "group also by > window")](https://github.com/apache/beam/blob/master/runners/direct-java/src/main/java/org/apache/beam/runners/direct/portable/DirectGroupByKey.java#L63-L70), > and the expectation is that the wrapped transforms are considered > "primitives", but the wrapper is not > > … in the wordcount case, the `Reshuffle` gets added as a primitive transform > (being a child of the otherwise-primitive `Read`) and, separately, its child > `RemoveRandomKeys` (URN `urn:beam:transform:pardo:v1`) gets marked primitive, > so there are two "primitive" transforms that have the same output > PCollection, failing [the > assertion](https://github.com/apache/beam/blob/9d0b03ad736797c33fbd6a4eb13155fa91367779/runners/core-construction-java/src/main/java/org/apache/beam/runners/core/construction/graph/QueryablePipeline.java#L176-L182). Basically I've been collecting cases where "primitive" transforms end up with descendents, and trying to do the right thing here as each comes to light! Definitely interested in guidance from folks like yourself that have a more complete "big picture" understanding of whether "primitives" should never have children (let alone deeper descendents; this was the original definition of "primitive" pre-#6328, but seemed to have false-positives and -negatives), or how to handle the cases where they do (if not how I've prototyped here). [ Full content available at: https://github.com/apache/beam/pull/6461 ] This message was relayed via gitbox.apache.org for [email protected]
