[
https://issues.apache.org/jira/browse/TINKERPOP-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16913784#comment-16913784
]
Mark Arciaga commented on TINKERPOP-2285:
-----------------------------------------
To reiterate Teonna's concern: AWS's response format is not problematic. It's
the handling of the status code that AWS returns that is the issue. As she
noted above, the block in which the issue occurs is:
```
if (response.status.code >= 400) {
return handler.callback(new Error(util.format('Server error: %s (%d)',
response.status.message, response.status.code)));
}
```
`response.status.message` is an object and not a string, which is what the
library assumes. I don't know where the issue is but if the AWS response is
being mis-consumed, that seems to me like a bug with the library. If the
expectation is that I need to build the Gremlin lib and debug this myself, by
all means let me know. I'm just not sure how to respond to the claim that AWS
is sending a message in an incorrect format.
> Error object is unreachable
> ---------------------------
>
> Key: TINKERPOP-2285
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2285
> Project: TinkerPop
> Issue Type: Bug
> Components: javascript
> Affects Versions: 3.3.8
> Reporter: Teonna Zaragoza
> Priority: Major
>
> In our currently application(React, node.js, Express), we are creating an
> edge between two existing nodes.
> {code:java}
> async function somethingThatQueriesGremlin() {
> try {
> const result = await theActualQuery();
> // ...
> } catch (error) {
> console.log(error); // I expect error to be useful and not a stringified
> instance of Error wrapped in an Error.
> }
> } {code}
> If the edge already exists, the error that is logged on the server is
> {code:javascript}
> Error: Server error:
> {"requestId":"e44b2c9a-9542-461b-9d1b-bc3db3f869f4","code":"ConstraintViolationException","detailedMessage":"Edge
> with id already exists: TEST|77886.105.1:NO_SIZE:0->WVN"} (499)
> at Connection._handleMessage
> (.../node_modules/gremlin/lib/driver/connection.js:265:9)
> at WebSocket._ws.on
> (.../node_modules/gremlin/lib/driver/connection.js:128:43)
> at emitOne (events.js:116:13)
> at WebSocket.emit (events.js:211:7)
> at Receiver._receiver.onmessage
> (.../node_modules/ws/lib/WebSocket.js:141:47)
> at Receiver.dataMessage (.../node_modules/ws/lib/Receiver.js:380:14)
> at Receiver.getData (.../node_modules/ws/lib/Receiver.js:330:12)
> at Receiver.startLoop (.../node_modules/ws/lib/Receiver.js:165:16)
> at Receiver.add (.../node_modules/ws/lib/Receiver.js:139:10)
> at TLSSocket._ultron.on (.../node_modules/ws/lib/WebSocket.js:138:22)
> at emitOne (events.js:116:13)
> at TLSSocket.emit (events.js:211:7)
> at addChunk (_stream_readable.js:263:12)
> at readableAddChunk (_stream_readable.js:250:11)
> at TLSSocket.Readable.push (_stream_readable.js:208:10)
> at TLSWrap.onread (net.js:607:20)
> object
> {code}
> The problem is that the actual error object with reachable keys is a string
> within another error object. The stringified object is reachable via
> err.message.
> The error comes from the driver in connection.js line 265
> {code:java}
> newError(util.format('Server error: %s
> (%d)',response.status.message,response.status.code)));
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
