Possible inconsistent behaviour about egeria-connector-ibm-information-server

[cmgrote]

Hi @lcpopa -- agreed this should likely be more consistent, but to help get to the root of the inconsistencies it would be great if you could clarify with some specifics:

• some specific examples of the methods you're using (you mention searching but the explanation is regarding instance GUIDs, which none of the search interfaces take as input, so I'm guessing you mean something like getEntityDetail?)
• building on those same examples, which specific method(s) (in which implementations) seem to be returning which specific exceptions

I believe RepositoryErrorException is intended to be thrown when there is some unexpected error like the underlying repository being offline, so probably shouldn't be used in the case where we simply know that an instance does not exist; however, this simply means that for this specific scenario we may be able to avoid it -- it does not mean that in general it will never be thrown back to the OMAS even if we solve this inconsistency. For example, if the underlying e.g. IGC repository goes offline the proxy may still validly need to respond with RepositoryErrorException as it won't even be able to check whether the entity exists or not in IGC (since IGC is offline).

[lcpopa]

Hi Chris,

Indeed the methods I am referring to are IGCOMRSMetadataCollection.getEntityDetail and EntityMapping.getEntityDetail. The first one will throw the EntityNotKnownException and the second the RepositoryErrorException

If we are to call with a non existent guid like 'mango', the EntityNotKnownException with code 4xx is thrown from IGCOMRSMetadataCollection.getEntityDetail:789

If we are to call with a non existent guid like 'kiwi@metadataCollectionId:papaya', the RepositoryErrorException with the 4xx code is thrown from EntityMapping.getEntityDetail:729. In order to pass the guid validation, it is important to have '@', and ':' in the proper order

We understand that we won't avoid RepoErEx in all cases, nor do we want that; when it is indeed the case it must be thrown. However, the callers (ex: omas) should get a consistent result since each exception is treated differently. In our case, the omas behaves as if IGC is down when the entity doesn't actually exists

Best wishes,
Liviu