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

node-report: meld into core #22712

Open
wants to merge 5 commits into
base: master
from

Conversation

@gireeshpunathil
Member

gireeshpunathil commented Sep 5, 2018

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

Make node-report part of core runtime, to satisfy its tier1 status
on diagnostic tooling

EDITed the rationale with @misterdjules 's input thus:

  1. When enabled, node-report significantly helps root cause various types of problems, including support issues sent to the various repos of the Node.js organization

  2. The requirement of explicitly adding the dependency to node-report in users' applications often represents a blocker to adoption and thus cancels 1) benefits

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:

  • opt-in feature for auto-generation of report through --report-events
  • APIs exposed through util module. APIs are enabled by default.
  • opt-out at configure time through --without-node-report
  • only minimal refactoring to natively merge the module
  • tests covering all the APIs and report generating events
  • a new page for node-report in the document section

Refs: #19661
Refs: #18760
Refs: nodejs/node-report#103

additional /cc

@rnchamberlain : original author of this component
@richardlau : previous work on merging this into core
@mhdawson : orignal requirement raiser through nodejs/node-report#110
@nodejs/diagnostics : in relation to nodejs/TSC#586
@jasnell @rvagg @joyeecheung : in relation to their specific requirements on interfaces /defaults (#19661)

[ 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 ]

@gireeshpunathil gireeshpunathil requested review from BridgeAR and bnoordhuis Sep 5, 2018

```js
const util = require('util');
const report_str = util.getReport();

This comment has been minimized.

@mcollina

mcollina Sep 5, 2018

Member

I would prefer this to go into @nodejs/report instead as there is some consensus in that direction.
Otherwise, I would go for util.report.generate() or something similar.

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

Another possibility would be util.generateDiagnosticReport(). I'm not convinced that a new standalone module (even scoped) is necessary for this.

This comment has been minimized.

@mcollina

mcollina Sep 5, 2018

Member

My overall concern is that this adds 3 different methods to util. Moreover, the docs for this is separate. Even if we do not want a separate method, just having a util.report namespace would be more user friendly.

(I would also avoid to load this until util.report  is accessed).

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

I'd be good with util.report with the methods:

  • util.report.getDiagnosticReport([error])
  • util.report.generateDiagnosticReport([filename][, error])
  • util.report.setDiagnosticReportOptions(options)

This comment has been minimized.

@joyeecheung

joyeecheung Oct 4, 2018

Member

@jasnell Can we use some abstractions (classes?) instead of going with aMethodWith20Letters?

This comment has been minimized.

@vipinmenon

vipinmenon Oct 6, 2018

Contributor

node report is with util.report now and the documentation is updated accordingly.

AUTHORS Outdated
@@ -2236,5 +2236,8 @@ Shelley Vohr <shelley.vohr@gmail.com>
Deepjyoti Mondal <djmdeveloper060796@gmail.com>
Brett Kiefer <brett@trello.com>
Kevin Thomas <kevintab95@gmail.com>
Richard Chamberlain <richard_chamberlain@uk.ibm.com>
Manusaporn Treerungroj <m.treerungroj@gmail.com>
Julian Alimin <unknown>

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

We really should have an email address for this one.

This comment has been minimized.

@targos

targos Sep 5, 2018

Member

The AUTHORS file should not be updated manually in this PR. We have tools/update-authors.sh for that and usually do it with a standalone PR.

This comment has been minimized.

@richardlau

richardlau Sep 5, 2018

Member

So that's an interesting question. These are authors for node-report who do not currently have commits in core so presumably won't be picked up by the tooling.

This comment has been minimized.

@targos

targos Sep 5, 2018

Member

I think what we are supposed to do to give attribution is to update the license with https://github.com/nodejs/node-report/blob/master/LICENSE.md.

This comment has been minimized.

@addaleax

addaleax Sep 5, 2018

Member

As far as attribution is concerned, there’s the Co-authored-by: field that is now recognized by Github. We should probably add support for it to our own AUTHORS tooling?

This comment has been minimized.

@addaleax

addaleax Sep 9, 2018

Member

Done in #22771@gireeshpunathil Can you make sure to add these to the commit metadata using Co-authored-by: name <email> accordingly?

This comment has been minimized.

@gireeshpunathil

gireeshpunathil Nov 28, 2018

Member

done, all the authors of the node-report module is now sourced into the commit message as co-authors.

Show resolved Hide resolved doc/api/node_report.md Outdated
```
A report will be triggered automatically on unhandled exceptions and fatal
error events (for example out of memory errors), and can also be triggered
by sending a USR2 signal to a Node.js process (not supported on Windows).

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

I would just say sending a SIGUSR2 signal...

This comment has been minimized.

@vipinmenon

vipinmenon Oct 6, 2018

Contributor

Done.

When a report is triggered, start and end messages are issued to stderr
and the filename of the report is returned to the caller. The default filename
includes the date, time, PID and a sequence number. Alternatively, a filename
can be specified as a parameter on the `triggerReport()` call.

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

Does this filename conform to typical require('fs') path rules? For instance, could I pass in a file URL here? triggerReport(new URL('file:///whatever'). If there are differences between this and what fs accepts, or if there are no differences, it should be noted here.

This comment has been minimized.

@vipinmenon

vipinmenon Oct 6, 2018

Contributor

The file name will be treated as file name in the local fs and no translation occurs on the passed string. Documentation is updated. quoting the same.

+ filename specifies the name of the output file in the file system
+ No translations occur to the supplied string, so URL protocols
+ are not supported.

this allows the report to include the location of the original error as well
as where it was handled.
If both a filename and `Error` object are passed to `triggerReport()` the
`Error` object should be the second parameter.

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

s/should/must

This comment has been minimized.

@vipinmenon

vipinmenon Oct 6, 2018

Contributor

Done.

util.setSignal('SIGUSR2|SIGQUIT');
util.setFileName('stdout|stderr|<filename>');
util.setDirectory('<full path>');
util.setVerbose('yes|no');

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

I'd prefer a single API call for this... something like:

// Changes all of the options
util.setDiagnosticReportOptions({
  events: ['exception', 'fatalerror', 'signal'],
  signal: 'SIGUSR2',
  filename: 'stderr',
  directory: '<full path>',
  verbose: true
});

// Only changes verbose, leaves other settings as they are
util.setDiagnosticReportOptions({
  verbose: false
});

This comment has been minimized.

@vipinmenon

vipinmenon Oct 6, 2018

Contributor

Done.

This comment has been minimized.

@gireeshpunathil

gireeshpunathil Nov 28, 2018

Member

we just have a single API now for configuring the report options, with every option made optional, aiming to improve the user experience when dealing with such an API (relatively long name, long list of options)

@@ -270,6 +270,26 @@ util.formatWithOptions({ colors: true }, 'See object %O', { foo: 42 });
// when printed to a terminal.
```
## util.getNodeReport()

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

This accepts an optional Error argument, correct?

This comment has been minimized.

@vipinmenon

vipinmenon Oct 6, 2018

Contributor

addressed, the whole section is modified and now includes this optional argument scenario as well.

```js
const util = require('util');
const report = util.getNodeReport();

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

Elsewhere this is getReport()

This comment has been minimized.

@vipinmenon

vipinmenon Oct 6, 2018

Contributor

The doc has completely changed due to change in the functional interface, and in that process these are fixed.

* `events` {string}
Runtime configuration of node report data capture. The string can be a comma-
separated list of one or more of:

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

The examples show this as a + separated list, not commas. In general, an array of individual values would be better.

This comment has been minimized.

@vipinmenon

vipinmenon Oct 6, 2018

Contributor

This is fixed and is documented.

@@ -919,6 +988,34 @@ encoded bytes.
The encoding supported by the `TextEncoder` instance. Always set to `'utf-8'`.
## util.triggerNodeReport([filename])

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

This accepts an optional Error object also, correct?

This comment has been minimized.

@vipinmenon

vipinmenon Oct 6, 2018

Contributor

addressed, the whole is modified.

* `filename` {string} The file to write into. **Default:** an empty string.
* Returns: {string}
Returns the filename of the generated report.

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

These are always sync, correct? If so, that should be noted.

This comment has been minimized.

@vipinmenon

vipinmenon Oct 6, 2018

Contributor

addressed, the documentation reflects itssynchronous now.

#if defined(NODE_REPORT)
const std::string& report_events = env->options()->report_events;
if (!report_events.empty()) {
READONLY_STRING_PROPERTY(target, "node_report", report_events);

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

Use camel case for the property here. s/node_report/nodeReport

This comment has been minimized.

@gireeshpunathil

gireeshpunathil Nov 26, 2018

Member

subsequent reviews and changes thereon made this change un-necessary; thanks.

@@ -129,6 +129,12 @@ EnvironmentOptionsParser::EnvironmentOptionsParser() {
"show stack traces on process warnings",
&EnvironmentOptions::trace_warnings,
kAllowedInEnvironment);
#if defined(NODE_REPORT)
AddOption("--report-events",

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

The naming on this is a bit odd and misleading. Why not just --node-report to enable?

This comment has been minimized.

@gireeshpunathil

gireeshpunathil Nov 26, 2018

Member

subsequent reviews and discussions evolved this into --experimental-report

@@ -203,7 +209,8 @@ PerProcessOptionsParser::PerProcessOptionsParser() {
kAllowedInEnvironment);
AddOption("--trace-event-file-pattern",
"Template string specifying the filepath for the trace-events "
"data, it supports ${rotation} and ${pid} log-rotation id.",
"data, it supports ${rotation} and ${pid} log-rotation id. %2$u "
"is the pid.",

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

This is an errant change... this was fixed in a PR yesterday I think.

This comment has been minimized.

@gireeshpunathil

gireeshpunathil Nov 26, 2018

Member

this if fixed.

} // namespace nodereport
#if defined(NODE_REPORT)
NODE_BUILTIN_MODULE_CONTEXT_AWARE(node_report, nodereport::Initialize)

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

this should use NODE_MODULE_CONTEXT_AWARE_INTERNAL and be exposed with internalBinding() instead of process.binding()

This comment has been minimized.

@gireeshpunathil

gireeshpunathil Nov 26, 2018

Member

made this change, thanks.

env->SetMethod(target, "setNodeReportDirectory", nodereport::SetDirectory);
env->SetMethod(target, "setNodeReportVerbose", nodereport::SetVerbose);
env->SetMethod(target, "triggerNodeReport", nodereport::TriggerReport);
#endif // NODE_REPORT

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

Why are these being exposed both here and in node_report_module.cc? These should not be exposed via the util internal binding.

This comment has been minimized.

@gireeshpunathil

gireeshpunathil Nov 26, 2018

Member

removed from here and exposed through util. However, subsequent reviews and changes thereon made some of these interfaces change their name and behavior.

return files.filter((file) => filePattern.test(file));
};
exports.isAIX = () => {

This comment has been minimized.

@jasnell

jasnell Sep 5, 2018

Member

Can you refactor this to use the module.exports = {} pattern... e.g.

function isAIX() {
  return process.platform === 'aix';
}

module.exports = {
  isAIX
};

In general, however, why expose separate is{Platform} checks here? Are the checks in common/index.js not suitable?

This comment has been minimized.

@gireeshpunathil

gireeshpunathil Nov 26, 2018

Member

subsequent reviews and changes thereon made this change un-necessary.

@jasnell

Good start. Needs a bit of work. Left some initial comments.

@richardlau

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.

Show resolved Hide resolved doc/api/node_report.md Outdated
Show resolved Hide resolved doc/api/util.md Outdated
Show resolved Hide resolved src/node_options.cc Outdated
Show resolved Hide resolved test/node-report/helper.js Outdated
Show resolved Hide resolved node.gyp Outdated
Show resolved Hide resolved doc/api/util.md Outdated
Show resolved Hide resolved doc/api/util.md Outdated
Show resolved Hide resolved doc/api/util.md Outdated
Show resolved Hide resolved doc/api/util.md Outdated
Show resolved Hide resolved src/node_report.h Outdated

@richardlau richardlau referenced this pull request Sep 5, 2018

Closed

[WIP] add node-report to core #19661

0 of 4 tasks complete
@misterdjules

This comment has been minimized.

Contributor

misterdjules commented Sep 5, 2018

@gireeshpunathil

Make node-report part of core runtime, to satisfy its tier1 status
on diagnostic tooling

What part of the tier1 status requires something to be part of Node.js' core?

Show resolved Hide resolved doc/api/node_report.md Outdated
Show resolved Hide resolved doc/api/node_report.md Outdated
Show resolved Hide resolved doc/api/node_report.md Outdated
Show resolved Hide resolved src/node_report.h Outdated
Show resolved Hide resolved src/node_report.cc Outdated
Show resolved Hide resolved src/node_report_module.cc Outdated
Show resolved Hide resolved src/node_report_module.cc Outdated
Show resolved Hide resolved src/node_report_module.cc Outdated
Show resolved Hide resolved src/node_report_module.cc Outdated
Show resolved Hide resolved src/node_report_utils.cc Outdated
@mhdawson

This comment has been minimized.

Member

mhdawson commented Nov 30, 2018

I'm off on vacation for a few weeks so I won't respond until I get back. Having said that I hope the discussion continues and more members of the diagnostics WG chime in.

@ofrobots

This comment has been minimized.

Contributor

ofrobots commented Nov 30, 2018

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.

@Fishrock123

Needs docs added to node.1.

@Fishrock123

This comment has been minimized.

Member

Fishrock123 commented Dec 1, 2018

Review aside I still have mixed feelings about this... this seems like it should be useful but the large apathy towards the node module really seems confusing to me.

@Fishrock123

This comment has been minimized.

Member

Fishrock123 commented Dec 1, 2018

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

@rvagg

This comment has been minimized.

Member

rvagg commented Dec 1, 2018

most core-collaborators would will chose to ignore it (as opposed to 'forced to invest in it').

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

@gireeshpunathil gireeshpunathil force-pushed the gireeshpunathil:nrmerge branch from 2780bc7 to 24d384f Dec 1, 2018

@gireeshpunathil

This comment has been minimized.

Member

gireeshpunathil commented Dec 1, 2018

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:

  • IMO, a major stake holder for the report is us, who support this platform, rather than end-users.

  • I have many examples from core and help repo where many dialogues and iterations were required to capture necessary information, that comes handy through this tool.

  • The concerning state of our issue backlog also have one reason directed to lack of diagnostic data.

  • Many forums I participated, many users I spoken to, and many surveys I reviewed, the tools, capability and turn around time for problem determination was reported as one among the major concerns.

Here is a sample of the generated report, for a better context and review.

From maintainance perspective:

  • I have made all the efforts to port this natively to the core (nomenclature, semantics, error check, composition, style, tests and documentation have almost underwent complete re-write) a lot of which I attribute to @addaleax and other reviewers.

  • We have changed the text based report to JSON-formatted one so that this can be consumed by programs such as logging and monitoring services.

  • Modularized the functions to a great extent, and have good in-line comments to suppliment.

  • Test coverage is comprehensive; we plan to review the tests to see if there are more paths that require testing.

  • And finally; I am open to discussions and suggestions towards amendments to any part of the changes in a way to help improve its usability as a first-class, first-failure data capture tool. Thanks!

requested changes addressed

Show resolved Hide resolved doc/api/cli.md Outdated
Show resolved Hide resolved doc/api/cli.md Outdated
Show resolved Hide resolved doc/api/cli.md Outdated
Show resolved Hide resolved doc/api/cli.md
Show resolved Hide resolved doc/api/cli.md Outdated
Show resolved Hide resolved src/node.cc Outdated
Show resolved Hide resolved src/node.cc Outdated
Show resolved Hide resolved src/node_report.cc
Show resolved Hide resolved src/node_report_module.cc Outdated
Show resolved Hide resolved src/node_report_module.cc Outdated
@addaleax

This comment has been minimized.

Member

addaleax commented Dec 1, 2018

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

Show resolved Hide resolved doc/api/cli.md Outdated
Show resolved Hide resolved doc/api/cli.md Outdated
Show resolved Hide resolved doc/api/node_report.md Outdated
Show resolved Hide resolved doc/node.1 Outdated
Show resolved Hide resolved src/node.cc Outdated
Show resolved Hide resolved src/node_report.cc Outdated
Show resolved Hide resolved src/node_report.cc Outdated
Show resolved Hide resolved src/node_report.cc Outdated
Show resolved Hide resolved src/node_report_module.cc
Show resolved Hide resolved test/common/report.js Outdated

@gireeshpunathil gireeshpunathil force-pushed the gireeshpunathil:nrmerge branch from b799635 to db4f96b Dec 3, 2018

@gireeshpunathil gireeshpunathil force-pushed the gireeshpunathil:nrmerge branch from 3f4c7c3 to 4f28c66 Dec 4, 2018

@gireeshpunathil

This comment has been minimized.

Member

gireeshpunathil commented Dec 5, 2018

finally got into a windows box, so porting to win32 atm. few glitches; but will get along.

@gireeshpunathil

This comment has been minimized.

@gireeshpunathil

This comment has been minimized.

Member

gireeshpunathil commented Dec 9, 2018

At this point I believe I have addressed all the review comments. Reviewers, can you please take another look? thanks in advance!

gireeshpunathil and others added some commits Sep 5, 2018

src: merge into core
Make node-report part of core runtime because:

1. When enabled, node-report significantly helps root cause various
types of problems, including support issues sent to the various repos
of the Node.js organization.

2. The requirement of explicitly adding the dependency to node-report
in user applications often represents a blocker to adoption.

Major deviation from the module version of the node-report is that the
report is generated in JSON format, as opposed to human readable text.

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)

Co-authored-by: Bidisha Pyne <bidipyne@in.ibm.com>
Co-authored-by: Howard Hellyer <hhellyer@uk.ibm.com>
Co-authored-by: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Co-authored-by: Julian Alimin <dmastag@yahoo.com>
Co-authored-by: Lakshmi Swetha Gopireddy <lakshmigopireddy@in.ibm.com>
Co-authored-by: Manusaporn Treerungroj <m.treerungroj@gmail.com>
Co-authored-by: Michael Dawson <michael_dawson@ca.ibm.com>
Co-authored-by: Richard Chamberlain <richard_chamberlain@uk.ibm.com>
Co-authored-by: Richard Lau <riclau@uk.ibm.com>
Co-authored-by: Sam Roberts <vieuxtech@gmail.com>
Co-authored-by: Vipin Menon <vipinmv1@in.ibm.com>
doc: add node-report documentation
a separate section added for node-report at top level
main documentation added to doc/api/node_report.md
API documentation added to doc/api/util.md
test: add node-report tests
One test per each API, so that additional tests in future are modular.
test/common/report.js contain common functions  that tests leverage.

@gireeshpunathil gireeshpunathil force-pushed the gireeshpunathil:nrmerge branch from 04db55f to 7c72fe2 Dec 10, 2018

@gireeshpunathil

This comment has been minimized.

Member

gireeshpunathil commented Dec 10, 2018

fixed few issues that were not captured locally but reported in CI.
Re-run CI: https://ci.nodejs.org/job/node-test-pull-request/19385/

@gireeshpunathil

This comment has been minimized.

Member

gireeshpunathil commented Dec 10, 2018

there are 3 types of failures in CI:
windows:

Creating library c:\workspace\node-compile-windows\Release\cctest.lib and object c:\workspace\node-compile-windows\Release\cctest.exp
04:37:36 node.lib(node_report.obj) : error LNK2001: unresolved external symbol _NetServerGetInfo@12 [c:\workspace\node-compile-windows\cctest.vcxproj]
04:37:36 node.lib(node_report.obj) : error LNK2001: unresolved external symbol _NetApiBufferFree@4 [c:\workspace\node-compile-windows\cctest.vcxproj]
04:37:36 c:\workspace\node-compile-windows\Release\cctest.exe : fatal error LNK1120: 2 unresolved externals [c:\workspace\node-compile-windows\cctest.vcxproj]

I guess I need to introduce the library (Netapi32.lib) against cctest target too apart from the node target, in node.gyp. Will see how to fix it.

freebsd:
all tests are failing. I am sure this has to do with platform specific code blocks - there are special considerations w.r.t windows, linux, aix and mac, somewhere I need to align the freebsd flow. I don't have a local box to debug this, so requested for a temporary access to CI

linux:
the usual suspect, test-cli-syntax. nothing to do for this for now, while the underlying issue being debugged and resolved / test is being marked flaky.

@gireeshpunathil

This comment has been minimized.

Member

gireeshpunathil commented Dec 10, 2018

pushed one commit that fixes the windows unresolved symbol issue.
windows-fanned CI: https://ci.nodejs.org/job/node-test-commit-windows-fanned/23155/

@sam-github

This comment has been minimized.

Member

sam-github commented Dec 13, 2018

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?

@sam-github sam-github referenced this pull request Dec 13, 2018

Open

tls: expose openssl library version #24999

0 of 4 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment