Skip to content

Detect problems with polymorphic epic trees

Alex Kalderimis requested to merge ajk-epic-tree-node-factory into master

What does this MR do?

We have encountered some problems where our tests were not thorough enough due to the failure to assume the existence of heterogeneous data in epic tree structures (where the neighbour of an item can be either an epic or an epic issue).

This MR introduces a new factory, epic_tree_node that is one or other of these two types, selected according to a sequence. This exposed some buggy behaviour which is addressed here.

The problem

As found in #247120 (closed) (which broke master), we incorrectly assumed that all relative positioning instances were monomorphic, and that id <> ? was a sufficient filter to find siblings.

However this is not true for the nodes in the epic tree, which can be either Epic or EpicIssue instances. This specific issue was fixed in !41986 (merged), but the underlying reason why this was not detected earlier is that we always tested on monomorphic sibling sets, and never on heterogeneous ones. For polymorphic models like EpicTreeSorting, this is insufficient, and some edge-cases were latent.

An example of one of these latent edge cases is if we load a record from epic.scoped_items and call #reset, this will have undefined behavior, because:

  • the class of the result is always an Epic, even if it actually represents an EpicIssue
  • calling reset loads the object from the epics table. If there happens to be a row with the corresponding ID there, it may or may not belong to the current object (which may or may not be an Epic).

The solution

This MR fixes the above edge case by supplying custom logic for resetting the relative position of an object loaded from a union. But more generally it weakens the assumptions in the use of the relative positioning shared examples, by allowing factory to build valid child nodes that are either epics or epic-issues.

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Edited by Alex Kalderimis

Merge request reports