Add logger for debugging
It would be really great if this package would use a (logging-compliant) logger that could be set to get better reporting when things go wrong.
How are we supposed to debug our apps atm? I'm a bit confused on how this is meant to be used. My server is running, but when something goes wrong, there is no output at all, and I have to start adding try/catch blocks in my code to get the location of the error. Is there another way to do this?
@kevmoo do you maybe have some tips for this? I'm really struggling with this.
A typical problem for me is this: Something goes wrong in my server, and my client gets this response:
gRPC Error (code: 2, codeName: UNKNOWN, message: Instance of 'EntityNotFoundException', details: [], rawResponse: null)
dart:async _StreamController.addError
package:grpc/src/client/call.dart 338:16 ClientCall._responseError
package:grpc/src/client/call.dart 357:7 ClientCall._checkForErrorStatus
package:grpc/src/client/call.dart 448:7 ClientCall._onResponseDone
dart:async _EventSinkWrapper.close
package:grpc/src/shared/streams.dart 141:10 _GrpcMessageConversionSink.close
===== asynchronous gap ===========================
dart:async _BoundSinkStream.listen
package:grpc/src/client/call.dart 320:54 ClientCall._onResponseListen
package:grpc/src/client/call.dart 297:5 ClientCall._sendRequest
package:grpc/src/client/call.dart 255:24 ClientCall.onConnectionReady.<fn>
===== asynchronous gap ===========================
dart:async Future.then
etc... etc...
And that's it basically. The server completely "swallows" the Error/Exception and I have to start debugging.
@enyo – are you using a Dart server, too?
Yes, I'm only talking about the dart server actually. As in: an exception is thrown in my grpc server code and the grpc library returns a 501 with the exception message but doesn't log anything that I can use to find the error.
Ah! That makes sense. CC @mraleph
CC @mit-mit
I don't really have any strong architectural opinion on how to debug. I just sprinkle print's around until I find the problem, but obviously this is not a scalable approach for deployed code.
I think the best I could suggest is to take ServerHandler_ and then add a configurable logging callback which is invoked from all places where _sendError is called. (also some places like _onResponseError should probably be changed to log stack trace as well) (and then add some plumbing so that you could set that callback when you create ServerHandler).
@mraleph I'm not sure I understand. Are you recommending this approach to be used by me, or is this something you suggest should be implemented to allow for this functionality? I couldn't find any place where ServerHandler could be defined.
@enyo I am saying somebody could modify grpc package implementation in the suggested way and expose ability to configure it externally through on Server constructor (similar to how server interceptors are plumbed through Server constructor all the way to ServerHandler_). I would be happy to review and merge such a PR.
Hi, is there any updates?
Linking to some best-practices for GRPC debugging (from the bug or otherwise) could be helpful. I'm currently exploring gRPC and hit some bug I don't understand and wound up here seeking debugging options. :)
https://github.com/flutter/devtools/issues/2044 points to some other efforts in this area.