Some gremlin-compatible endpoints (such as Azure CosmosDB Graph) provide additional metadata in the message which is useful for processing. It's possible to retrieve this information using a custom executeHandler, but the metadata is swallowed when an error occurs, making it impossible for a client to retrieve it.
This change adds a rawMessage property to the error emitted so that clients can retrieve additional structured information from the message when errors occur. I'm also open to any suggestions for other approaches/field names. I went with this because it was simple and non-breaking without limiting the available information.
Some gremlin-compatible endpoints (such as Azure CosmosDB Graph) provide additional metadata in the message which is useful for processing. It's possible to retrieve this information using a custom
executeHandler
, but the metadata is swallowed when an error occurs, making it impossible for a client to retrieve it.This change adds a
rawMessage
property to the error emitted so that clients can retrieve additional structured information from the message when errors occur. I'm also open to any suggestions for other approaches/field names. I went with this because it was simple and non-breaking without limiting the available information.