Skip to content

Conversation

@ueman
Copy link
Collaborator

@ueman ueman commented Jul 24, 2021

📜 Description

Bildschirmfoto 2021-07-24 um 17 26 41

The information in the red square is added by this PR.

💡 Motivation and Context

💚 How did you test it?

Changed test accordingly

📝 Checklist

  • I reviewed submitted code
  • I added tests to verify changes
  • I updated the docs if needed
  • All tests passing
  • No breaking changes

🔮 Next steps

@ueman ueman requested a review from marandaneto as a code owner July 24, 2021 15:29
@codecov-commenter
Copy link

codecov-commenter commented Jul 24, 2021

Codecov Report

Merging #538 (63e5c94) into main (db3cde2) will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##             main     #538   +/-   ##
=======================================
  Coverage   91.55%   91.55%           
=======================================
  Files          74       74           
  Lines        2428     2428           
=======================================
  Hits         2223     2223           
  Misses        205      205           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update db3cde2...63e5c94. Read the comment docs.

Copy link
Member

@bruno-garcia bruno-garcia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How often can the information field be larger than what Sentry can display properly? It transforms an array into a single line, so it could end up truncated or not fitting the UI very well. Perhaps we need to find another way to present it?

@ueman
Copy link
Collaborator Author

ueman commented Jul 25, 2021

How often can the information field be larger than what Sentry can display properly? It transforms an array into a single line, so it could end up truncated or not fitting the UI very well.

Hard to say as its origin can be the Flutter framework, libraries and developers themselves.
So it's probably better to assume that it can be very long.

Perhaps we need to find another way to present it?

What would be a better way to display this?
As far as I can tell, the only data which is displayed as a text block is the exception description.

The events data could be another place for this, but then the information would be visually disconnected in the Sentry UI :(

@ueman
Copy link
Collaborator Author

ueman commented Jul 26, 2021

It doesn't play nicely if it's really long :( I raised an issue for this little UI bug here: getsentry/sentry#27737
Bildschirmfoto 2021-07-26 um 08 47 01

Comment on lines +149 to +168
RaisedButton(
child: const Text('Capture from FlutterError.onError'),
onPressed: () {
// modeled after a real exception
FlutterError.onError?.call(FlutterErrorDetails(
exception: Exception('A really bad exception'),
silent: false,
context: DiagnosticsNode.message('while handling a gesture'),
library: 'gesture',
informationCollector: () => [
DiagnosticsNode.message(
'Handler: "onTap" Recognizer: TapGestureRecognizer'),
DiagnosticsNode.message(
'Handler: "onTap" Recognizer: TapGestureRecognizer'),
DiagnosticsNode.message(
'Handler: "onTap" Recognizer: TapGestureRecognizer'),
],
));
},
),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the example Flutter error : Scaffold.of() already triggers a FlutterError.onError error, isnt that enough? is it common that people trigger FlutterError.onError manually too?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the example Flutter error : Scaffold.of() already triggers a FlutterError.onError error, isnt that enough?

This is just to test how it looks in the Sentry UI when it has a long trail of information, which Flutter error : Scaffold.of() doesn't have (as seen in the screenshot of the PR description). We can remove it before merging.

is it common that people trigger FlutterError.onError manually too?

No, but it's not uncommon in libraries.

@marandaneto
Copy link
Contributor

@ueman is this ready to be merged or the multiple line thing should be tested?

@ueman
Copy link
Collaborator Author

ueman commented Jul 29, 2021

@ueman is this ready to be merged or the multiple line thing should be tested?

It works and is tested but it could be that it doesn't look that good in the Sentry UI for long information. So unless you or @bruno-garcia has a better idea where to put the information this is good to go.

I tried to add it to the events extra data, but then this information kinda gets lost.

@marandaneto
Copy link
Contributor

I tried to add it to the events extra data, but then this information kinda gets lost.

what do you mean by kinda get lost? does it make to Sentry or not easy to find since the information is down there in the additional data?
just trying to understand if we have a bug or not.

@ueman
Copy link
Collaborator Author

ueman commented Jul 29, 2021

I tried to add it to the events extra data, but then this information kinda gets lost.

what do you mean by kinda get lost? does it make to Sentry or not easy to find since the information is down there in the additional data?
just trying to understand if we have a bug or not.

It gets visually lost when it at the same place as all the device, os and app information. It does make to Sentry so it's not a bug.

I'll add some pictures later to clarify what I mean :D

@ueman
Copy link
Collaborator Author

ueman commented Jul 29, 2021

This event has the data added to the mechanism and as the crash_context. At the top I think it's really useful, though it might not look good for long text, just like @bruno-garcia said. At the bottom, the information gets kinda visually lost next to all the meta data.
sentry io_organizations_sentry-sdks_issues_2535239328__project=5428562 query=is%3Aunresolved

@bruno-garcia
Copy link
Member

I'm a bit wary of adding data that'll be potentially large in that field in this form. Perhaps best we find a way to break in up in more 'key/value' pairs

@bagedevimo
Copy link

This is looks amazing for us, as we have 3 different flutter apps all using this context data and we've only just realized it's missing. Very keen to help out in any way that I can.

@ueman
Copy link
Collaborator Author

ueman commented Aug 5, 2021

This is looks amazing for us, as we have 3 different flutter apps all using this context data and we've only just realized it's missing. Very keen to help out in any way that I can.

Thanks! That's really appreciated.
Do you mind answering the following questions?

  1. How long are your context and information values?
  2. What length of these fields have you seen in the wild?
  3. How would you like to see these fields in the Sentry UI?

@bagedevimo
Copy link

Our context fields are typically 3-4 words, similar length to your example. We have none longer than 36 characters. I'm afraid we've never seen information values in practice, as Sentry isn't capturing them :P. Looking at the definition of FlutterErrorDetails, it seems reasonable to suggest these should be key/value pairs, but as far as I can tell you could only split on the newlines that may or may not exist. Seems fine for most use-cases? I don't know a lot about the Sentry UI though sorry. A neat UX might be that if a tag is too long up the top, it is cut off and can be clicked to scroll down to the full value.

@ueman
Copy link
Collaborator Author

ueman commented Aug 7, 2021

Okay, I've changed it so that the mechanism has a tag which tells the user to look for a flutter_error_details context down below. Down there, everything displays well. I hope that is satisfying for all :D

@ueman ueman merged commit a5127ce into main Aug 11, 2021
@ueman ueman deleted the feat/improve_on_error branch August 11, 2021 12:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants