egeria: RELEASE 2.9 - CTS failures with graph repo (retrievable via GUID)

Running CTS against the graph repo on a k8s cluster (4x16GB, 4 cpu, openshift) when testing release 2.9 in #5075 resulted in many failures: (Inmemory did not show these issues)

       "testCaseCount": 5017,
        "testFailedCount": 442,
        "testPassCount": 4575,

The full report is at https://ibm.box.com/s/gavxl77rfblfmrkdu9pts0cm7bzjm91c

Some of the examples of failures include:

                            "repository-relationship-reidentify-06: GroupedMedia relationship retrievable by new GUID."

In the cases I’ve looked at so far the issues appear to relate to GUIDs

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 18 (18 by maintainers)

Commits related to this issue

#5086 resolves persistence of the new reIdentifiedFromGUID core property on instances in the graph repository connector Signed-off-by: Christopher Grote <chris@thegrotes.net> — committed to cmgrote/egeria by cmgrote 3 years ago
#5086 resolves persistence of the new reIdentifiedFromGUID core property on instances in the graph repository connector Signed-off-by: Christopher Grote <chris@thegrotes.net> Signed-off-by: Nigel Jon... — committed to planetf1/egeria by cmgrote 3 years ago

Most upvoted comments

Have corrected in the following locations, re-building and then re-testing:

GraphOMRSConstants - adding constants for the property name and persistence-layer keys
GraphOMRSGraphFactory::initialize - building indexes for both entities and relationships on this new property
GraphOMRSEntityMapper - mapping the new property to and from persistence in Janus (for entities)
GraphOMRSRelationshipMapper - mapping the new property to and from persistence in Janus (for relationships)

… will be a few hours before I have results, but assuming this fixes the problem, should I PR & push to master and then we cherry-pick from there back to the release branch, or … ?

cmgrote on Apr 28, 2021

So to the CTS failure itself, I’ve run locally with debug-logging turned on and it would appear that the failing assertion is most likely the assertion in the CTS that the re-identified object returned by the call to reIdentify[Entity|Relationship] does not equal the entity pulled back from the repository by a call to getEntityDetail with its new GUID.

I suspect this is because we’ve introduced the new reIdentifiedFromGUID property on the InstanceHeader, which I am only now seeing that the graph repository does not appear to map dynamically (only the InstanceProperties appear to be dynamically mapped for persistence).

I therefore suspect that the inequality is because the EntityDetail that is being returned from the reIdentifyEntity method has its reIdentifiedFromGUID populated, while the one retrieved back from the graph (persistence) does not have this property since it has not been explicitly mapped as part of the graph repository’s non-InstanceProperties mappings.

Looking at correcting that now to re-test…

cmgrote on Apr 28, 2021