Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
node-report: meld into core #22712
EDITed the rationale with @misterdjules 's input thus:
No new functionalities have been added, changes that are required for melding it as a built-in capability has been affected on the module version of node-report (https://github.com/nodejs/node-report)
Changes at a glance:
@rnchamberlain : original author of this component
[ Note: I wasn't able to test this on Windows, my box is broken at the moment. Apologies in advance if it fails over there ]
Thanks @gireeshpunathil! Did a cursory glance over and left some comments. Will follow up with a proper technical review.
Docs should note that this feature is experimental (at least initially). I also have a preference for calling the report
diagnostics report (or something similar) instead of
node-report in core as I find the
node- prefix redundant.
There are a large number of issues in our issue tracker that mention segfaults. Generally segfault bug reports are of low quality. If you peruse through the diagnosis process, you will notice that resolution requires a core-collaborator to reproduce the issue. In some cases – where we have sophisticated enough users – we typically ask them to run things in a native debugger like gdb or lldb. Many issues go un-reproduced and undiagnosed to the root cause.
As a core collaborator, I would very much like the first error report to be as useful as possible in the diagnosis. Having worked on other language runtimes, I know that this experience can be significantly better. We want users to be able to report issues from production, and us not having to ask them to reproduce them in a debugger. We would be able to fix a lot more issues from the initial report of failure than we are able to do today.
This is a low-level feature, and I expect most core-collaborators would will chose to ignore it (as opposed to 'forced to invest in it'). That doesn't make it any less important to our users – specially enterprise – and the collaborators that end up looking at native crash reports.
That being said, I do think there is node core incentive to add something.
Ever seen those CI crashes? You get like an exit code and that's it. Sure there might be a core dump somewhere but like, are we actually gona be able to get it? Hah. No.
If something like this is able to solve that...
You know that's not how tightly coupled systems work @ofrobots. Small changes have wide effects and a contributor is forced to expand well beyond their small focus because of unintended effects. Often the test suite will tell them this, the CI system adds a new layer, and then users come in and report problems where we have gaps (like the tick processor in 8.x which is still broken for --prof-process).
just pushed one commit that contain the manual page update for the report flags. @Fishrock123, ptal.
@rvagg - thanks for sharing the concerns. This is my thoughts around some of those:
From usability perspective:
Here is a sample of the generated report, for a better context and review.
From maintainance perspective:
@rvagg So… I can see where you’re coming from, but I’m not quite as concerned as you are. The code here has changed significantly from the initial version of this PR, and just from getting familiar with it I wouldn’t expect this to become an unreasonable maintenance burden, like e.g. trace events currently are.
We’ve also come some way during the almost 700 comments in this thread (I’d expect that to be some kind of record); a number of these comments are about things that affect maintainability, e.g. working towards more modularity in the code.
And, maybe most importantly, if this lands, we can still pull it out as long as it’s experimental – I know we haven’t used that possibility so far, but it’s there, and this is not a very invasive feature as you can see by the diff stats (i.e. it would be easy to pull back out, even if we make some changes to it in the future).
referenced this pull request
Dec 4, 2018
fixed few issues that were not captured locally but reported in CI.
referenced this pull request
Dec 10, 2018
there are 3 types of failures in CI:
I guess I need to introduce the library (Netapi32.lib) against cctest target too apart from the node target, in
pushed one commit that fixes the windows unresolved symbol issue.
Any chance node-report could be triggered by an uncaught exception by default? If the first report of #24658 had included process.versions it would have been obvious from the start that node had been built against an unsupported openssl version.
I assume this isn't doing that now in an effort to be unobtrusive, but in this case, we want obtrusive.
Also, perhaps a note in the output to include the output if a bug is being reported to nodejs? Or maybe that should be in the nodejs/node issue template?