Replies: 6 comments
-
Improving GraphQL noiseGraphQL has no concept of a status code out of the box like a REST API would. The downside of this is that all flavors of errors are lumped together. So things like a validation error (e.g. backend returning "first name is required) would be reported as error which adds noise and makes it harder to find real errors (e.g. a 500 error). |
Beta Was this translation helpful? Give feedback.
-
Ruby stacktraces are incompleteRuby stacktraces only include the line number. They don't even include the method that reported the error. We should be able to capture the source. |
Beta Was this translation helpful? Give feedback.
-
Release/Version visibility on errorsIf I attach a version, I should be able to see the version somewhere on the error instance page.
|
Beta Was this translation helpful? Give feedback.
-
Release/Version top level pageFor a given version in Highlight.io, I want a top level page to get an overview of what has changed and what errors occurred in that version. To really get value here, I may need Highlight to connect to my github repository. |
Beta Was this translation helpful? Give feedback.
-
This is not a comment on the error monitoring itself, but rather how to set it up. We're currently not using the error monitoring features as I've been dragging my feet getting source mapping setup. Not sure if I'm alone on this, but the friction of correctly setting up source map uploading is so high that I've been postponing it for months. :) This prevents me from having much use of the error monitoring since the stack traces won't tell me anything. Two ideas on this:
|
Beta Was this translation helpful? Give feedback.
-
Check Documentation and FAQs: Before reporting an issue, make sure to check the project's documentation, README file, or any FAQs that might address common problems. Search the project's issue tracker on GitHub to see if someone else has already reported a similar issue. This can help you avoid duplicate reports. When reporting an issue, be as detailed as possible. Include information about the error, steps to reproduce it, and any relevant context such as operating system, browser, or environment. Include any error messages or stack traces you encounter. This information is crucial for developers to understand the nature of the problem. Specify details about your environment, such as the operating system version, browser version, programming language version, and any relevant dependencies. If applicable, include screenshots or code snippets that help illustrate the issue. This can provide additional context for developers to understand the problem. Use a title that clearly summarizes the issue. A concise and descriptive title can make it easier for developers to identify and prioritize the problem. Some projects may have specific guidelines for issue reporting. Check the project's CONTRIBUTING guidelines, if available, and follow any instructions provided. Remember that open-source maintainers and contributors are volunteers. Be respectful and patient, and understand that it may take some time for them to address the issue. Stay engaged in the conversation. Respond to any follow-up questions or requests for additional information. This helps the maintainers address the issue more efficiently. |
Beta Was this translation helpful? Give feedback.
-
Hey folks 👋
This quarter we are investing a lot more time into improving our error monitoring product. We are looking for feedback from people who may (or may not) be currently using Highlight to monitor errors in their app to understand where we can be improving.
Ideas could include:
But anything is fair game! Your feedback will help us drive the product going forward and makes bugs easier to solve.
Beta Was this translation helpful? Give feedback.
All reactions