[
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16381018#comment-16381018
]
Florian Hockmann commented on TINKERPOP-1906:
---------------------------------------------
Yeah, seeing the exception message I can completely understand your confusion.
The thing is that Gremlin.Net just builds the exception message as
{{$"\{status.Code}: \{status.Message}"}} where {{status.Code}} isn't an {{int}}
but a {{ResponseStatusCode enum}}. From your {{message.txt}}, the
{{status.code}} is {{ServerError}} and everything behind that (starting with
the {{ActivityId}}) is the {{status.Message}} returned by Cosmos DB.
This means for Gremlin.Net that all we're seeing here is the {{ServerError}}
(which corresponds to the status code 500) and the rest is just a {{string}}.
So all we could do with that information is to add dedicated exception class
like {{GremlinServerErrorException}} in cases where the server returns a
{{ServerError}} (500), but I don't know how useful that is as the
{{ServerError}} could be basically anything.
> Make ResponseException explorable
> ---------------------------------
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
> Affects Versions: 3.2.7
> Reporter: Roman Kreisel
> Priority: Major
> Attachments: message.txt, stacktrace.txt
>
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to
> react on the GremlinService's Response. The only content is the exception's
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode
> or anything else that's responded by the service.
>
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a
> "Request Rate to Large" response, in case you have high load on your
> database. In such a case, you want to be able to detect this "error" and just
> retry after a few milliseconds (i'm not sure, but i think even a proposal for
> this retry-timeout is given in the response)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
