This PR addresses two issues with parsing Bolt responses:
1. The nature of OPTIONAL MATCH queries means there is a potential for returning "null" fields in a Bolt result. However, this raised errors when a null field was parsed for something like "identity.low" (which doesn't exist for a null field), so the graph wouldn't end up rendering. I've added some checks so that null fields are skipped and the other potential fields (Node, Relationship, Path) are still passed along for proper rendering.
2. The original logic would check the first field in the Bolt result for a certain property: `if (result._fields[0].hasOwnProperty('segments'))`. If it existed, then it would assume there was only one field in the result and it was a Path. If it didn't exist, then it would loop through each field and assume it was either a Node, Relationship, or Array with nested Node/Relationship fields. The problem arises when a query returns both a Path and some other field (Name/Relationship). For example, if the Path was listed as the first RETURN param, then it would be rendered and all other fields would be ignored. The opposite is also true -- if a Node/Relationship was listed as the first RETURN param, then any Path fields would be ignored. I've reordered some of the logic so that each field is parsed in turn instead of having a mutual exclusion between Path and Node/Relationship fields.
I came across these while toying with some custom queries. As far as I can tell, none of the existing BloodHound queries use OPTIONAL MATCH or have a RETURN clause with both a Path and a Node/Relationship, so they shouldn't be affected by the current configuration. Merging this PR would be a boost for those using custom queries :)
Rohan Vazarkar
Andy Robbins
Martin Sundhaug
Rohan Vazarkar
HarmJ0y
Rohan Vazarkar
Tom Porter
Carter