Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add logger for debugging #51

Closed
stevenroose opened this issue Jan 24, 2018 · 12 comments · Fixed by #588
Closed

Add logger for debugging #51

stevenroose opened this issue Jan 24, 2018 · 12 comments · Fixed by #588

Comments

@stevenroose
Copy link

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.

@enyo
Copy link

enyo commented Oct 25, 2020

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?

@enyo
Copy link

enyo commented Apr 5, 2021

@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.

@kevmoo
Copy link
Contributor

kevmoo commented Apr 5, 2021

@enyo – are you using a Dart server, too?

@enyo
Copy link

enyo commented Apr 6, 2021

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.

@kevmoo
Copy link
Contributor

kevmoo commented Apr 6, 2021

Ah! That makes sense. CC @mraleph

@kevmoo
Copy link
Contributor

kevmoo commented Apr 6, 2021

CC @mit-mit

@mraleph
Copy link
Member

mraleph commented Apr 6, 2021

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).

@enyo
Copy link

enyo commented Apr 12, 2021

@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.

@mraleph
Copy link
Member

mraleph commented Apr 12, 2021

@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.

@fzyzcjy
Copy link

fzyzcjy commented May 2, 2022

Hi, is there any updates?

@eseidel
Copy link

eseidel commented Jun 20, 2022

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. :)

@eseidel
Copy link

eseidel commented Jun 20, 2022

flutter/devtools#2044 points to some other efforts in this area.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants