►
From YouTube: 2020-02-24-Diagnostics WG 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
Okay,
so
welcome
to
the
node.js
diagnostics
working
group
meeting
for
february
24th
2021
we'll
follow
the
agenda
that
was
in
the
issue
before
we
get
started.
Actually
one
of
the
things
I'm
going
to
do
is
I'll
paste
the
link
to
the
issues
that
people
can
add
themselves
to
the
the
minutes
as
the
attendance.
But
does
anybody
have
any
announcements
they'd
like
to
share
or
anything
like
that.
A
If
not
we'll
move
on
to
the
issues
which
were
tagged
for
the
agenda,
the
first
one
is
asynch
hooks
new
v8
context,
promise
hook.
I
pretty
sure
that
stephen
you've
been
working
on
that
one.
B
Yep
I
was
working
on
that
a
bit
like
before
christmas
and
then
kind
of
took
like
about
a
month
long,
just
code
holiday
and
now
I
joined
the
datadog
officially
on
monday
and
I'm
back
on
to
this
now
so
on
monday,
I
dealt
with
the
couple
of
remaining
nets
that
the
v8
team
had
on
my
changes
there,
I'm
still
still
just
waiting
to
see
if
that
gets
accepted.
A
B
Yeah
yeah,
when,
when
I
left
it,
it
was
like
very
close
there's
just
like
a
handful
of
naming
changes
and
things
like
that
that
needed
to
happen:
okay,
great
and
the
the
node
pr
for
it.
I'm
currently
working
on
redoing
that
there's
some
small
changes
that
need
to
be
made
to
the
node
code,
nothing
significant
and
I
need
to
redo
the
v8
patch
commit
which,
for
some
reason,
when
I
tried
to
do
it
yesterday,
it
wasn't
applying
cleanly.
C
A
B
A
Yeah,
that's
what
I
was
just
wondering
like
do
you
want
to?
I
I
don't
think
it's
a
big
deal
like
happy
to.
We
could
leave
it
on
the
agenda
or
we
could
take
it
off
and
you
could
put
it
back
on
when
you
want
people
to
do.
You
want
us
to
ask
you
about
it.
Every
meeting,
I
guess,
is
the
question.
B
Well,
I'm
aiming
to
have
it
like
ready
for
a
review
like
by
the
time.
The
next
meeting
rolls
around
okay,
so.
A
A
A
That
one,
basically,
you
know
january
6th,
it's
like
unless
there's
any
objections
we
plan
to
move
forward
with
merging
node,
inspect
and
decor.
We
plan
to
share
a
decision
broadly
next
monday
1pm,
so
there
were
like
six
plus
ones,
no
concerns.
So
I
think
we
can
just
close
this
issue.
Unless
there's
you
know
something
to
discuss.
People
have
concerns.
B
A
Right,
so
are
people
comfortable?
You
know,
there's
been
enough
enough
times.
I
see
six
plus
six.
I
guess
like
I
don't
you
know.
There's
is
there
anybody
here
like
legenda
cass,
I
don't
see
a
plus
one
but
and
same
with
gerhard,
but
it's
you
know.
I
assume
you
two
would
be
raising
objections.
If
you
had
any
here.
D
A
A
A
Okay,
the
next
one
is
number
437,
which
is
async
hook,
use
cases
beyond
async
local
storage.
Again
I
I
believe,
stephen
you
opened
that
one
and
the
goal
was
to
get
some
feedback
to
say,
like
you
know
what
alternate
apis
might
we
might?
We
want
to
make
available
as
alternates
to
using
async
hooks
directly
right.
B
A
A
A
Right,
so,
if
we,
I
guess
like
for
the
medium
blog
post,
what
I
usually
just
do
is
send
an
email
to
rachel
who's
in
on
the
foundation
side
to
say:
hey,
like
here's,
a
blog
post,
we'd
like
to
go
on
the
foundation
blog
and
then
they
handle
getting
it
out
there.
And
so,
if
you
want
to
write
something,
I
could
then
connect
you
into.
You
know
basically
just
to
make
the
connection.
If
that's
helpful,
yeah
sounds
good.
Okay,
so
yeah.
A
If
you
write
the
blog,
so
basically
I'll,
say
chord,
you
write
first
draft
and
I'm
happy
to
like
you
know
if
you
want
some
feedback
or
you
know
somebody
to
go
through
and
and
read
it
in
advance,
I'm
happy
to
do
that
as
well,
and
then
I'll.
We
can
forward
on
to
let's
write
first
draft
and
michael
to
connect
with
rachel
and
so
forth,
which
will
just
really
be
an
email.
So
not
nothing.
Really.
There
magic.
A
A
A
A
A
C
A
Then
node
ins,
the
next
issue,
is
node,
inspect,
update,
add
black
box
by
default.
This
is
pr
number
99..
Let's
go,
take
a
look
see
if
that's
still
open
or.
B
C
Week
is
so
it's
not
an
agenda
if
someone
of
you
has
used
the
esm
models
already.
C
Now
the
esm
models
is
someone
investigating
this
one
regarding
diagnostics
use
cases,
because
you
know
we
can't
market
batch
then
because
there
is
no
loader,
there
is
a
loader
hook,
but
they
are
still
experimental
and
just
a
single
hook
is
available
and
yeah.
So
for
all
these
epm
use
cases
which
are
a
lot
of
interest
here,
I
would
say
it's
currently
not
usable,
so
I
have
not
found
the
time
till
now
to
really
dig
into
this
somewhat
of
you
taking
a
look
into
this
area
already.
E
So
the
modules
working
group
did
spend
time
and
we
wrote
an
example:
apm
loader,
even
going
that
far
the
loader
api's
changed
since
we
wrote
that
example,
but
we
could
update
it
in
general.
They
don't
work.
How
apms
work
today
you
because
esm
is
statically
linked.
E
You
can't
just
replace
out
the
values
on
a
module,
so
in
general
the
idea
is,
you
can
use
a
policy
or
you
can
use
a
loader
both
require
it
to
be
set
up
before
any
evaluation
is
done,
because
once
the
esm
graph
is
linked,
it's
too
late,
so
you
can't
put
a
require.
You
can't
put
an
import
at
the
start
of
your
application.
E
It's
too
late
at
that
point,
and
so
I
would
say
the
loader
hooks
are
very
unstable,
there's
a
lot
of
pushback
whenever
we
try
to
update
them,
which
is
unfortunate,
but
there
are
known
issues
with
them.
E
E
C
And
even
if
you
have
more
of
them
than
the
questionnaires,
if
you
have
more
apm
tools
and
then
they
try
to
modify
the
source
in
the
similar
way
somehow,
so
this
in
the
end
doesn't
really
look
like
a
stable
waveform,
but
I
would
say
so,
for
example,.
B
This
issue
is
actually
like
one
one
of
the
primary
targets
of
the
diagnostics
channel
work
that
that
I
did
basically
like
just
trying
to
sidestep
completely
the
whole
idea
of
patching
a
module.
So
instead,
like
you,
could
just
ask
the
module
author
or
like
make
your
own
pull
request
to
a
module
to
just
submit
diagnostics,
channel
information.
Then
you
don't
you
don't
need
any
patches.
C
Yeah
I'd
say
it
more
or
less
the
same
yesterday
on
telemetry,
because
this
is
this
mostly
the
same,
I
would
say
just
not
badass
node
it's,
but
it's
an
and
model
which
can
be
used
to
to
send
out
your
diagnostic
information,
but
yeah
you
have
to
convince
the
world
to
use
it.
C
C
C
E
We
we
took
a
few
potential
solutions
to
tc39
that
all
got
rejected.
They
generally
all
shared
the
same
name,
unfortunately
called
dynamic
module
records
that
basically
allowed
us
to
loosen
some
of
the
constraints
of
es
modules.
E
Unfortunately,
due
to
things
like
steven
was
saying,
the
committee
simply
doesn't
want
them
to
be
loosened
because
doing
so
means
the
spec
has
to
deal
with
a
lot
more
complexity
and
potential
error
conditions,
and
they
just
would
rather
have
an
early
error
than
try
to
guess
what
the
programmer
is
trying
to
do.
A
E
A
C
My
colleague
of
mine
is
currently
looking
into
it
for
difficulties
on
slowing
so
indiana
and
yeah.
I
was
just
asking
if
there's
other
work
done
so
because,
I'm
quite
sure
in
the
end,
all
of
us
having
to
do
with
apm
will
need
something
and
it.
B
Of
time
spent
on
it
at
datadog
and
that's
kind
of
part
of
what
led
to
me
creating
diagnostics
channel,
even
though
that
was
an
idea
I
had
like
long
before
esm,
but
kind
of
like
sparked
their
interest
in
it,
but
yeah
they're
from
what
I
understand
like
their
investigation
and
it's
pretty
much
came
to
the
same
like
we
don't
have
an
answer
kind
of
assessment.
B
It's
it's
a
difficult
situation
and
no
one's
really
sure
how
to
solve
it
in
a
good
way
or
if
there
even
is
a
good
way
to
solve
it.
But
I'm
I'm
somewhat
thinking
that,
like
we're,
just
gonna
have
to
deal
with
like
a
relatively
major
change
to
how
apms
work
to
just
migrate
to
some
something
else.
Like
diagnostics
channel.
That
gets
very
different
pattern
from
what
we
deal
with
now.
E
C
B
Yep
yeah,
so
the
the
main,
the
main
issue
that
we,
like
diagnostics
in
general
always
seems
to
have
is
a
lot
of
our
features
are
marked
as
experimental
and
the
community
doesn't
like
using
things
that
are
marked
as
experimental.
So
we
need
to
work
on
getting
things
marked
was
not
experimental
at
some
point
so,
like
I
already
have
some
other
issue
open.
B
Some
are
suggesting
migrating
it
at
least
async
resource
to
being
stable,
since
it
pretty
much
is
already
yep
and
aiming
to
get
basic
local
storage
too
stable
as
soon
as
possible,
as
well.
A
A
B
Yeah
and
like
placing
global
storage,
has
been
the
default
context,
management
for
datadog
for
a
while
now
so
there's
like
very,
very
major
users
using
it
in
production
and
it's
not
having
issues
so.
B
B
A
A
You
could
probably
make
a
pretty
good
case
across
that,
like
especially,
you
know,
if
you
can
bring
the
hey,
this
has
been
used
in
real
life
and
production
by
the
you
know
through
the
data
dog
customers
that,
given
the
fact
that
you
know,
I
don't
think,
there's
too
much
of
it.
You
know
there
hasn't
been
much
churn
and
if
you
know
from
your
use
and
experience
you're
pretty
comfortable
that
you
know
the
the
work
you
need
to
do
to
you
know
continue
to
improve
performance
won't
require
api
changes.
B
A
B
Like
that,
but
that
same
sort
of
thing,
like
that
same
getting
stuff
out
of
experimental
thing,
it
just
kind
of
became
a
tangent
off
of
that.
But
it
applies
as
well
to
like
diagnostics.
Channel
there's
been
like
some
adopters
of
it
so
far,
but
eventually
we
will
have
to
discuss
marking
it
stable
to
convince
more
people
that
they
should
be
using.
B
A
E
C
Yeah,
it's
experimental
because
the
awesome
cooks
itself
are
experimental
and
the
essentials
without
desense
makes
no
sense,
because
you
have
nothing
which
consumes
it
and
getting
housing.
Hooks
stable
is
in
the
end
hard
because
it
exposes
internals,
but
now
with
us
in
global
storage,
we
have
the
option
that
we
have
a
consumer
which
can
be
also
put
out
of
experimental,
which
does
not
expose
this
entire
anymore.
So
this
looks
quite
promising.
C
B
Yeah
that,
and
also
like
the
async
hooks
api
and
the
async
resource
api
are
decoupled
enough
that
it's
actually
like
entirely
possible
that,
like
basic
local
storage,
we
could
rip
out
async
hooks
entirely
and
just
rebuild
it
at
a
lower
level
and
still
have
async
resource
function.
E
B
B
E
I
believe
it
eats
the
air,
but
sets
something
the
the
reason
it
has
to
eat.
The
air
is
to
ensure
that
all
the
hooks
fire.
C
C
So
you
know
monkey
batching
is
done
a
lot
in
the
wild
to
which
is
completely
unrelated
at
all,
sometimes
through
the
apm
use
cases,
but
the
diagnostics
channel
is
not
intended
to
fix
all
of
them,
so
it's
just
to
to
get
the
help
that
austin
stayed
quite
similar
to
yeah,
I
would
say,
telemetry
trace
part
is
intended
to
do.
C
B
So
that
diagnostic
channel
is
very,
you
know,
is
very
much
intended
to
be
a
non-destructive
system.
Nothing
like
no
behavior
of
the
source
module
should
change.
It
should
only
just
reports,
whatever
information
it
has
technically.
B
In
some
cases
you
could
like
mutate
data,
that's
passed
through
if
they
decided
to
just
pass
objects
directly
through,
but
it's
not
recommended
you
do
that.
B
Yeah
for
for
anything
that
wants
to
like
actually
manipulate
the
environment,
I
I
would
almost
question
like
why
do
you
want
to
do
that?
Why
not
just
like
ask
the
module
author
for
a
feature
to
change
stuff
through
some
api
or
something,
but
I
mean
I'm,
maybe
not
aware
of
all
the
possible
use
cases
outside
of
apm.
So.
E
A
A
D
D
D
Actually,
if
this
is,
it
is
expected-
or
this
is
a
bug
inside
the
pattern
matching
and
we
are
actually
waiting
for
someone
who
worked
in
this
situation
to
give
us,
I
don't
know
kind
of
like.
A
D
D
A
Okay,
so
any
other
issues
or
do
we
want
to
go
back
to
the
the
dsm
issue
or
close
out.