►
From YouTube: 2020-11-25 Node.js Diagnostics Working Group Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
The
first
two
items
we
have
related
to
diagnostics
channel
those
are
two
pull
requests
that
stephen
opened.
Stephen
won't
be
able
to
join
today.
So
I
don't
think
we
have
enough
context
to
discuss
this,
but
he
asked
it
please
for
someone
to
review
those
requests
so
that
they
can
land
and
if
anyone
in
the
meeting
or
anyone
listening
can
review
those
requests.
That
would
be
great.
A
Those
are
to
improve
the
diagnostics
channel
api
that
has
landed
on
no
jazz
15.
I
think
not
sure
if
it
was
back
part.
I
don't
think
so.
B
A
Okay,
so
yeah.
If
anyone
can
help
review
those,
I
can
try
to
help
review
today
or
tomorrow,
since
this
week
is
a
lot
less.
B
A
B
B
A
Yeah,
the
this
pen
api
has
some
discussion
at
least
yep.
The
sync
terrible
has
no
discussion
so
far,
so
I
I
think
it
would
be
good
to
start
with
testing
it
terrible
also
just
just
looking
at
what
each
proquest
is
adding,
I
think
I'd
be
more
inclined
to
add
the
sinker
terrible
than
the
span
api.
B
B
I'm
I'm
kind
of
like
in
in
some
cases
unless
there's
some
poll,
it's
like
it's
definitely.
I
think
it
was
non
like
if
we
looked
at
the
files
that
were
changed,
it
wasn't
a
small
amount
of
changes.
So
anyway,
I
think
if
you
take
a
look
and
then
form
an
opinion
that
would
be
good,
like
mine,
wasn't
strong
enough
to
say
yes
or
no,
but.
A
Okay,
I'll
try
to
get
to
it
to
there
tomorrow.
C
For
me,
I'm
good
with
the
diagnostic
channel,
the
pr
that
is
landed,
I'm
fully
bought
into
that.
But
from
the
span
api
perspective,
I
had
a
first
pass
the
view
of
the
span
api.
C
Unfortunately,
I
am
finding
it
little
bit
difficult
to
either
understand
or
figure
out
how
the
span
is
going
to
be
used
within
the
diagnostic
channel
to
be
useful
to
be
added
as
a
mainstream
capability.
C
A
Yeah,
so
I
think
both
are
great
questions
to
ask
in
the
pr
first
how
it's
going
to
be
used
within
the
danger
6
channel.
I
think
this
even
should
be
part
of
the
documentation.
If
it's
not.
A
A
C
Yeah
I
mean
the
the
best
I
can
I
could
understand
from
the
span
is
like
we
have
number
of
apm
vendors
access
and
if
you
look
at
the
diagnostic
channel,
it's
a
it's
an
event
bus.
You
can
think
about
it
as
a
is
a
producer
and
consumer
of
diagnostic
data
and
the
data
gets
consumed
in
an
endless
manner
in
a
production
system.
So
how
do
we
define
delimiters?
C
How
do
we
define
custom
custom
structure
for
the
logs
or
traces?
That's
coming
in?
That's
where
the
span
comes
in
that's
the
best
I
could
understand
so
probably
based
on
different
apms
and
their
use
cases.
They
require
exact
requirements.
We
could
still
iterate
over
the
span
based
as
to
what
should
be
the
structure
of
the
span.
B
And
it
is
probably
something
that,
like
you
know,
the
modules
or
packages
could
create
their
own
span,
values
and-
and
you
know
basically
do
it
on
their
own
as
well.
So
this
kind
of
goes
back
to,
I
think
the
earlier
comment
of
like
maybe
you
know,
the
existing
diagnostic
channel
can
be
used
a
little
bit
and
get
more
feedback
before
adding
more
things,
as
is
along
the
lines
of
what
I
was
thinking
too.
B
A
A
target
for
how
many
producers
we
want
using
the
api
before
we
start
adding
new
things.
A
B
Yeah
or
or
like
things
that
we
don't
think
are
needed
to
make
it
like.
If
there's
something
that's
needed
to
make
to
gain
adoption,
then
totally
right
but
like
we
don't
need
to
build
out.
If,
if
we
don't
think
it's
something
that
need
is
needed
for
adoption,
then
maybe
we
could
wait
until
there's
a
couple
couple
of
consumers
that
would
make
sense
yeah.
That
makes.
B
A
A
B
Yeah,
I
think
we
pretty
much
agreed
on
our
exit
on
our
next
steps.
One
is
like
to
define
a
set
of
exit
criteria
for
async,
local
storage
and
I
guess
async
resource
it
seemed
like
there
was
consensus.
It
could
be
stable,
but
talking
with
core
it
was
like
it
wasn't
certain
that,
like
it
would
make
sense
to
do
one
versus
the
other.
B
So
I
don't
think
you
you
know
there
wasn't.
There
was
nobody
who
was
saying
it
was
a
big
rush
to
do
that.
If
we
were
gonna,
wait
on
async
local
storage.
B
A
B
A
Yeah
yeah,
so
basically,
the
proposal
is
to
blackbox
by
default,
our
scripts
that
are
internal
to
node.js,
so,
for
example,
a
fast
child
process
of
those
black
box
sims.
So
when
you
step
into
a
function
or
step
out
of
a
function,
you
don't
end
up
in
a
code
that
is
internal
to
node.js.
A
A
Yeah,
I
think
it
is
or
not
internal
colon,
maybe.
A
A
A
Use
the
debugger
set
black
box
pattern
command
on
node.js
to
filter
out
those,
though
yeah
those
modules.
Someone
just
needs
to
volunteer
to
do
this
work,
so
this
is
on
the
agenda
as
a
call
for
action
to
someone
that
is
interested
in
working
on
this,
in
improving
typical
ability
on
chrome,
devtools.
B
B
Yeah,
I
guess
yeah.
A
B
B
B
A
I'm
not
sure
about
if
we
can
remove
it
from
the
dot
stack.
B
A
B
A
Is
chrome,
devtools
doesn't
have
a
way
to
highlight
if
a
function
is
internal
or
not,
and
it
has
a
feature
that
allows
you
to
black
box
a
module
so
that
step
instead
out,
doesn't
enter
that
function,
that
module.
B
A
B
A
So
chrome
devtools
allows
you
to
remove
a
black
box
pattern:
okay,
so
for
card
developers
that
shouldn't
be
an
issue.
You
just
need
to
remove
right.
B
B
B
C
A
jump
from
a
would
directly
be
shown
as
an
entry
to
function
c,
with
a
complete
bypass
of
b.
Is
that
the
actual
requirement.
A
My
guess
is:
that's
how
the
devtools
feature
works.
I
haven't
tried
it
actually.
C
C
Okay
and
you
said
to
make
that
com
work
complete,
somebody
has
to
actually
look
at
the
inspector
code.
Is
that
correct.
C
A
Inspector
code
on
node.js-
okay,
that
that's
the
idea
at
least
we
are.
We
are
mostly
guessing
that
this
can
be
implemented
on
node.js
or
not
on
from
laptops.
Someone
just
needs
to
dig
deeper
to
make
sure
that
it
is
implementable
or
if
we
need
to
drop
it,
because
it
would
need
to
be
implemented
on
chrome,
devtools,.
B
And
I
guess
this
is
I'm
going
to
paste
the
link
from
the
chat?
Sorry
from
the
issue,
this
is
probably
the
the
comment.
Did
I
yeah
that's
the
link
that
shows
the
example
of
what
joey's
thinking
might
work.
B
A
Yeah,
that's
that
should
be
enough
to
black
box
node
modules.
D
But
did
this
feature
needs
to
be
built
inside
the
from
the
tools
or
inside
the
node
inspector
protocol?.
B
C
B
B
B
D
Yeah
this
one
was
created
because
the
cpu
profiler
was
done
and
the
the
remaining
task
is
the
improved
abh
profiler
performance
at
production
environment,
because,
depending
on
what
what
application,
how
many
functions
are
on
top
of
the
application?
D
A
D
B
I
I
guess
it's
like,
would
we
use
the
you
know?
We
have
an
acme
air
benchmark
and
we
have.
D
B
B
D
A
A
D
D
So
I
will
engage,
and
so
we
need
to
create
some
test
cases
and
after
it
create
a
benchmark
on
the
node.js
benchmark.
So
to
be
sure
of
this
problem
and
after
work
on
it,
this
is
the
the
workflow.
A
Yes,
it's
better
to
work
on
to
work
with
the
v8
team
on
fixing
a
performance
issue.
If
we
can
demonstrate
the
performance
issues
so
having
a
reproducible
benchmark
is
probably
the
best
way
to
start
this
issue.
D
D
B
No,
I
think
that
this
is
just
about
what
are
the
use
cases
that
we
need
to
cover
beyond
what's
covered
by
async
local
storage.
You
know,
along
the
lines
of
we
don't
necessarily
think
async
hooks
will
get
to
be
stable,
but
there
may
be
some
other
apis
higher
level
different
apis
that
we
do
need
to
build
on
top
of
it
kind
of
like
async
local
storage,
but
to
cover
whatever
the
other
use
cases.
So
this
is
to
like
identify.
What
are
those
other
use
cases.
B
A
A
A
A
We
only
have
15
minutes
left,
so
I
don't
think
we
can
go
into
a
deep
dive
right
now.
Does
anyone
have
anything
else
they
would
like
to
discuss.
D
I
I
have
a
question.
The
the
last
missing
on
the
the
working
group
is
the
the
normal
agenda
is
not
a
deep
dive.
We
can
sell
all
the
meetings
from
the
dive.
D
I
I
mean
I
don't.
I
don't
think
that
we
we
have
the
the
sorry
you
can
continue.
I
can
ask
you
later.
A
So
that
we
could
use
the
second
half
of
the
regular
meetings
to
do
the
deep
dive
instead
of
having
a
meet
weekly
meeting,
the
main
reason
was
because
our
regular
agenda
was
not
as
packets
as
it
is
right
now.
B
A
A
D
A
A
I
think
it's
a
matter
of
tidying
up
the
agenda
and
making
sure
that
the
items
we
have
there
are
really
worth
discussing.
So
basically
what
michael
said.
A
D
Nope,
I
guess
the
the
meeting
will
stay
at
at
this
time
or
we'll
move
for
another
time.
A
Leverages
those
that
can
join
the
meeting
so
it
spies
it
towards
so.
The
time
now
is
good.
I
think
we
almost
have
enough
information.
They
should
to
make
a
decision.