- Recording: https://www.youtube.com/watch?v=ve9x5aanbfU
- GitHub Issue: #308
- Michael Dawson (@mhdawson)
- Gireesh Punathil (@gireeshpunathil)
- Peter Marton (@hekike)
- Naugtur
- Chris H.
*Extracted from diag-agenda labelled issues and pull requests from the nodejs org prior to the meeting.
- Async Hooks do not recognize execution contexts created when processing thenables #22360
- M: I don’t see any discussion from meeting attendees
- M: it sounded something like may need changes from the JS engine
- N: in some cases we are losing context, but I don’t see conclusion
- N: there is an issue around Bluebird context support
- M: maybe it’s already fixed
- N: they switched from domains
- N: it may need to be propagated by V8
- M: next step is not clear on this, someone should take a lead on it
-
seeking feedback: diagnostic report tooling #301
- M: let’s move on as we are missing lead from this meeting
- Chris is giving a demo of “gnostic”
- Gnostic can diff multiple Diagnostic Reports
- Gnostic can be also used as a library
- Support rules to check on long-running eventloop and other characteristics
- There is an API for rule developers
- Can sanitize reports
- Transformations (use cases like plot a graph or pipe to unix tool)
- Chris: what are the use cases for Diagnostic Reports?
- Peter: we are planning to build a crash analysis system which needs sanitization and hashing for reports (stack traces)
- M: I see a value in a solution that can community reuse and it could live in Gnostic
- C: project is not public yet but hopefully it will be soon, I can share the slides
- M: will it be MIT? Apache?
- C: Apache?
- N: Process running out of memory use-case, people trying to use Node Report
- N: they don’t have time to learn about it. I believe it would be useful if Gnostic comes with recommended/default recipes to lower the entry barrier
- M: For example trouble with getting core dumps, check for ulimit in reports
- C: maybe asking what;s wrong instead of what do you want to do?
- N: I’d like id sanitizing code would be available separately for reusing it
-
proposal: --inspect-store flag #298
- M: Any context Peter, I think it’s related to Netflix’s efforts?
- P: I’m not sure, but I can ping Mattheus
- N: it’s one the agenda to consider using diagnostics report to ???
- M: we need Aleksei to make progress
-
Proposal to drive Diagnostics WG initiatives through user journeys #295
- P: two action items
- P: one to send out survey (Peter to create issue and include link)
- P: two to: schedule first deep dive on first use case (Peter to open issue and propose date)
- P: let’s start with deep drive that we already started to work on it
- G: I can help to review survey, also would like to see questions around use-case / user journey gaps
- Peter will open a Google docs for collaboration and turn it to a form later
-
Perfetto in Node.js #277
- Skip as we don’t have the right people for an update.
-
Diagnostics "Best Practices" Guide? #211
- Gireesh -> discovered under user journeys.
- Gireesh: #285 is the starting point for the best practices document, Given that crash and memory are already agreed to be important no harm working on these in parallel.
- Peter: should we add to survey, is there anything to ask?
- M: for example, what’s the level of knowledge people already have?
- N: based on my survey experience in user experience research the recommendation was to start with a situation how do they deal instead of asking for solutions, like asking how to deal with specific use-cases like crashing process? Should we mention paid tools to ask on OSS tools? Would it be overstepping to mention paid tools?
- P: I’ll add a TODO section about best practices questions to the survey docs and people can add if they have something to ask
-
Diag WG Deep Dives - topics #168
- no update.
-
[async_hooks] stable API - tracking issue #124
- no update
-
Async-context formalization and diagnostics support #107
- no update
- Node.js Foundation Calendar: https://nodejs.org/calendar
Click +GoogleCalendar
at the bottom right to add to your own Google calendar.