Description
Hi! This is definitely a feature request to get more visibility into what is going wrong when using the NodeJS Datastore client library.
Is your feature request related to a problem? Please describe.
At various points using the library (using async/await semantics), we've had issues where errors would be thrown. However, our application is fairly large so it can be hard to tell from the stack traces where things are going awry – or even what underlying Datastore API is being handled. For example, this is what one recent production Datastore exception gives us (@google-cloud/datastore version 6.6.2):
"Error: 14 UNAVAILABLE: read ECONNRESET
at Object.callErrorFromStatus (/webpack:/path-to-our-app/node_modules/@grpc/grpc-js/build/src/call.js:31:1)
at Object.onReceiveStatus (/webpack:/path-to-our-app/node_modules/@grpc/grpc-js/build/src/client.js:180:1)
at Object.onReceiveStatus (/webpack:/path-to-our-app/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:365:1)
at Object.onReceiveStatus (/webpack:/path-to-our-app/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:328:1)
at /webpack:/path-to-our-app/node_modules/@grpc/grpc-js/build/src/call-stream.js:182:1
at processTicksAndRejections (internal/process/task_queues.js:77:11)"
Additionally, almost all exceptions thrown by the Datastore client are type Error. There is no way to catch Datastore specific exceptions except to ensure any calls to it are very closely enclosed in try/catch and wrapped with another exception.
Describe the solution you'd like
Some or all of the following would be nice:
- A base class for exceptions thrown by the Datastore client. One thing this would allow is including (since it's part of the API contract) whether or not the operation requested is retryable or not.
- Stack traces that include some indicate of what Datastore API is being done. Is this happening during a query? A write operation? No way to tell.
- If possible, stack traces that include what client library function is being called that resemble the function names our code is calling.
- If possible, stack traces that include the calling context. I am not sure this is possible given NodeJS and how it does async/await.
Describe alternatives you've considered
We have mitigated the client throwing bare Error by wrapping all call sites with our own exception. Note the issue is not that the exception is being thrown, bu that it's fairly non-trivial to figure out what call point it's happening from and whether we need to change anything to address it.
Thank you!
Rachael Ludwick (from Glowforge)