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
