I would look at it from the lens of the user (gremlin client) experience. The server should provide the details of the error if the user could either take a corrective action or apply a workaround. As an example, in the StackOverflowError error you quoted, a customer can reduce the length of the query they are submitting to the server (which could be sometimes as simple as replacing some steps with repeat()).
For errors which are not a function of user input or user configuration, we can provide back a generic form of InternalServerError. An example here would be when the underlying storage is unavailable. In such cases, a user cannot take any action (unless they have access to the server in which case we will call their role as operator), and hence, a generic retriable error would suffice. Thoughts? -- Divij Vaidya On Fri, Feb 3, 2023 at 3:01 AM Cole Greer <cole.gr...@improving.com.invalid> wrote: > Hi everyone, > > A question came up on this PR< > https://github.com/apache/tinkerpop/pull/1946> which I think is worthy of > a broader discussion. The current state of the server is that if an > uncaught error or an exception is thrown during a gremlin script traversal, > the server will return that error/exception (stack trace and all) to the > client in its response message. It will do the same thing if an exception > is thrown during a bytecode traversal, but currently the server will never > reply at all if an error is thrown during bytecode traversal. The PR in > question fixes this by having bytecode traversals also return errors but it > has opened the question of if this is truly the right behaviour. > > I think there is a good argument that we shouldn’t be giving clients too > much information about how certain requests may have been able to break > things on the server. Using the example of a StackOverflow on the server, I > think it would be sufficient if the server logged the StackOverflowError > and then sent some sort of generic “TraversalExecutionFailedException” to > the client. There are certainly many exceptions such as evaluation timeouts > and malformed query exceptions which we would still want to surface to the > client with some specificity. If we do think it’s best to obfuscate some > errors, there will need to be some consideration of exactly where the line > should be drawn between failures we should transparently surface and ones > which should be replaced with a generic failure message. > > I’m wondering if anyone else has any opinions on this. Does anyone find it > valuable to surface every error in full detail to clients? Do people > believe the server should not reveal that much detail? Does anyone have > other suggestions as to how the server should behave when a traversal fails? > > If there is no traction on this thread, I will assume a lazy consensus > supporting the status quo and that no changes should be made other than > adding error responses to bytecode traversals. > > Regards, > > Cole Greer >
