►
From YouTube: Diagnostics WG meeting October 20th 2020
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).
B
Not
nothing
super
major,
but
I'm
currently
working
on
a
rewrite
of
promise
hook.
Well,
a
parallel
version
of
promise
hook
that
uses
javascript
functions
instead
of
c
plus
functions,
so
we
can
bypass
like
all
of
the
overhead
of
that,
should
be
pretty
helpful.
B
It's
kind
of
half
done
right
now
and
I
have
some
local
changes
that
haven't
been
synced
to
that
yet,
but
that's
kind
of
just
a
quick
like
a
quick
hack
together
new
promise
hook,
api.
B
But
yeah
that
that
lets
you
register
like,
rather
than
having
one
c
plus
plus
function
to
handle
all
hooks.
You
handle
each
type
of
hook
as
a
separate
function
and
so
it'll
check
if
it
needs
to
even
run
anything
for
each
individual
type
of
hook,
which
should
have
somewhat
better
performance,
and
it's
all
like
javascript
functions.
So
it
can
insert
it
in
place
in
the
in
so
it
well
most
places
they
can
insert
it
in
place.
B
So
it
should
make
a
lot
of
it
quite
a
bit
faster,
there's
a
handful
of
places
where
the
event
needs
to
be
triggered
within
a
runtime
function,
which
I
think
that
won't
really
have
as
good
as
a
performance
as
the
ideal.
But
I'm
still
kind
of
working
through
to
see
like
what
I
can
pull
out
into
generated
code.
B
It's
complicated
and
how
promises
are
generated
in
v8
is
kind
of
a
big
tangled
mess.
So
it's
it's
hard
to
figure
out
exactly
where
to
put
things
to
get
the
best
performance,
but
just
doing
what
I
can.
D
B
Yeah,
so
I
I've
been
working
on
diagnostics
channel,
and
I
have
two
issues
in
the
agenda
that
I
basically
pulled
out.
Some
features
that
I
guess
were
controversial
to
some
extent
or
just
couldn't
as
easily
get
consensus
on
them.
The
span
api
is
the
first
one
which
there
just
wasn't
really
enough
consensus
on
like
what
what
a
contact
like,
but
what
a
correlation
api
should
look
like.
B
It's
not
like
spans,
specifically
like
the
ultimate
intent
is
just.
We
need
to
be
able
to
say
that
a
bunch
of
events
are
related
in
some
way.
So
like
say,
we
have
a
diagnostics
channel
in
an
http
server.
We
we
want
to
be
able
to
say
this,
like,
like
all
of
these
events
happen
within
the
same
request
in
this
http
server,
so
you
might
have
like
a
request
started.
B
So,
like
response
ended
like
done
parsing
the
body
or
something
like
that
done,
the
body
stream,
it
might
be
like
a
handful
of
events
like
that.
You
want
to
be
able
to
correlate
all
of
them
to
the
same
requests.
So
there
needs
to
be
some
sort
of
like
correlation
identifier,
to
link
them
all
together.
So
I
I
put
forth
this
span
api
idea,
which
is
the
pretty
basic
object
that
just
when
you
constructed
it,
it
emits
a
start
and
it
has
annotation
events.
B
You
can
have
any
number
of
them
in
the
middle
and
then
there's
an
end
to
delineate
the
like
it's.
This
is
the
end
of
correlation
events,
for
this
correlation
id
and
like
all
it
does,
is
attach
an
id
to
this
chunk
of
data,
but,
like
the
particular
shape
of
the
api,
I
think
people
were
uncertain
about
so
yeah.
I
pulled
it
out
to
this
separate,
pull
request
and
needs
some
more.
E
Channel
muted,
the
only
question
I
had
is
like
just
does:
it
need
to
be
a
separate
api.
E
B
Yeah
it
the
exact
shape
of
it,
doesn't
really
matter
that
much
it's
just.
The
general
concept
of
apm
wants
to
be
able
to
link
a
bunch
of
events
together
in
some
way,
so
there
needs
to
be
at
some
level
a
correlation
id
saying
like
these.
Two
things
are
from
the
same
thing
right.
How
that
is,
how
that
is
delivered
is
largely
irrelevant
as
long
as
it
works.
E
Yeah
the
concept
to
me-
I
absolutely
I
can
I
can
I
see
that
the
need
for
that
I
was
just
wondering
like
I
could
see
it
is
you
know
when
you
actually
say
here's
an
event.
If
there
was
just
this
optional
span
id
that
would
be
quite
a
might
be
a
smaller
change
or
less
complicated
or
than
a
separate
api,
and
I'm
just
you
know
it
may
be
that
no,
you
need
something
more
sophisticated
and
you
know
a
separate
api
makes
sense.
I
was
just
wondering
on
that
front,
though.
B
Yeah
yeah,
it's
mainly
just
you
know.
We
need
a
shared
id
between
things
there.
There
is
an
advantage
to
also
having
a
clear
delineation
of
a
start
and
end
just
for
like
cleanup
purposes.
B
It
makes
it
easier,
but
it's
not
strictly
required,
like
we
could
stuff
things
in
a
weak
map
or
something,
but
it's
just
easier
if
we
have
something
like
the
current
api
that
has
little
more
clear,
like
encapsulation
of
the
lifetime
of
this
thing,.
B
B
It's
a
sequence
of
events,
so
I
just
had
this
idea
to
just
make
the
channel
object
an
async
interval,
so
you
can
just
use
like
a
408
loop
over
it
to
get
the
messages
out
of
it.
B
It's
it's
not
really
very
important.
It
was
just
like
kind
of
nice
to
have
idea
and
I
tried
it
out
and
tried
to
see
if
it
was
valuable
to
anyone,
but
it
didn't
really
get
any
real
feedback
on
it
and
like
it,
it
does
add
a
little
bit
of
extra
complexity
like
it's.
It's
fairly
self-contained,
but
it
does
add
a
little
bit
of
extra
code
that
needs
to
be
maintained.
I
guess
so
it's
just
a
matter
of
deciding
like.
B
A
So
I
was
just
wondering
whether
the
channel
will
be
consumed
by
the
sync
or
the
end
points
in
the
form
of
a
stream,
as
opposed
to
be,
as
opposed
to
an
iterable
enumeration.
B
So
I
think
the
typical
use
of
it
would
just
be
like
directly
with
the
subscribe
api
which
you
just
have
it's
like
an
event
handler.
You
just
have
a
function
that
is
called
whenever
a
message
comes
in.
B
Yeah,
that's
that's
part
of
the
reason
why
I
pulled
it
out
to
a
separate
pull
request,
because
the
core
diagnostics
channel
pr
itself
now
is
fairly
simple,
fairly
non-controversial
and
so,
like
I,
I
think,
that's
mostly
in
a
state
that,
like
people,
would
be
okay
with
landing
that
and
then
it's
just
this
like
span
api
and
the
async
interval
api
that
I
just
pulled
out
because,
like
it's
it's
code,
that's
already
done
so.
B
D
On
the
activity
channel,
jagannath
channel.js
on
the
yeah
have
a
comment
about
to
change
it,
the
interface
to
c
plus
plus.
I
don't
understand
the
motivation
to
change
this
to
by
c
plus.
D
No,
I
think
in
terrible
the
issue.
Three
five,
five,
three
two.
D
B
B
Yeah
yeah
that
that's
comments,
yeah,
I
think
I
know
what
you're
referring
to
now.
That's
just
a
reminder
like
so
far.
I
don't
think
there's
anywhere
that
we
actually
need
to
amiss
data
to
channels
in
c
plus
anywhere,
but
if,
if
we
do
discover
somewhere
that
we
actually
want
data
from
in
c
plus
we'll
have
to
make
some
sort
of
interface
to
connect
a
c
plus
plus
side
version
of
this
to
the
javascript
side
and
haven't
really
thought
too
deeply
about
what
that
would
look
like
or
like.
B
Yeah
native
modules
are
like
most
of
the
use
case.
Of
diagnostics.
Channel
is
for
core,
it's
just
emitting
core
related
stuff
and
like
specifically
being
able
to
in
insert
events
anywhere
that
there's
like
again
and
an
async
barrier
that
we
want
to
capture
data
about
that
right.
E
B
B
Yeah
yeah,
so
that
that
had
some
comments,
async
resource
seems
to
be
fairly
uncontroversial
that
it
should
probably
be
considered
stable.
At
this
point,
I
think
local
storage,
I
think
the
consensus
was
we
should
let
it
bake
a
bit
longer,
and
there
was
like
a
bunch
of
discussion
around
the
enter
with
method
specifically,
which
bradley
seemed
to
be
not
too
fond
of,
so
we'll
have
to
figure
out
something
we
can
do
with
that
to
make
it
more
acceptable.
B
Week,
yeah
yeah,
we
we
want
to
try
and,
like
I
guess,
like
I
said,
not
exactly
a
deadline
but
like
a
gold
like.
Ideally,
we
should
be
able
to
call
this
stable
by
some
version.
Node
16-
maybe
I
don't
know,
but
we
should
work
towards
a
point
that
we
can
call
it
stables
and
have
some
actual
intent
of
doing
that,
rather
than
just
getting
experimental.
E
B
And
the
the
main
main
concern
I
had
with
all
of
it
was
just
the
push
back
against
the
ender,
with
we'll
have
to
figure
out
a
better
way
to
do
that
so
get
enter
with.
Is
the
main
api
that's
needed
by
apm,
and
there
seemed
to
be
some
disagreement
that
it
should
be.
A
B
Yeah
yeah
that
they
can
definitely
act
separately
it
it's
only
really.
I
only
really
proposed
them
together,
because
I
was
thinking
about
them
at
the
same
time
and
like
at
least
in
my
use
case,
the
combination
of
the
two
is
where
we
get
the
advantage
marking
async
resource
on
its
own
as
stable
has
a
little
bit
less
advantage
because
it's
basically
feeding
into
an
unstable
api,
whether
that's
async
hooks
or
async
local
storage.
B
So
it's
maybe
less
critical
that
it's
it's
that's
considered
stable
immediately,
but
also
it.
It
does
mean
that
we
could
at
least
get
the
ecosystem
and
start
adopting
it,
and
hopefully,
by
the
time
async
local
storage
is
considered
stable
enough.
Async
resource
usage
would
exist
in
the
wild
that
we
could
just
turn
on.
Async
local
storage
is
stable
and
suddenly
all
this
stuff
just
works.
B
Yeah,
that
was
the
main
motivation
for
trying
to
mark
async
resources
as
stable
yeah,
because
there's
several
modules
I
think
mongoose
was
one
of
them
that
have
like
some
sort
of
internal
cueing
system
that
breaks
continuation
and
they
refuse
to
use
async
results
because
it's
considered
experimental,
even
though
it
hasn't
changed
at
all
in,
like
literally
years.
B
E
That
that's
more
just
we
failed
to
go
through
the
process
of
not
make
of
making
it
like
officially
stable,
right
yeah.
It's
different
consumers
right.
So
I
can
see
it
like.
The
consumers
of
async
resource
are
the
are
the
modules
we
want
to
have.
You
know,
use
it,
and
then
the
consumers
of
async
local
storage
are
actually
the
apms,
and
so
you
could
easily
see
the
case
where
the
modules
are
like.
Well,
we
don't
want
to
do
all
this
work
until
we
know
this.
E
B
E
B
Yeah
yeah,
that's
a
to
me
yeah.
I
think
resource
could
be
considered
as
stable
separately
from
async
local
storage
or,
if,
if
we
wanted
to
bundle
the
two
together,
that's
fine
too.
I
guess
the
only
real
advantage
to
marketing
async
resources
stable
before
async
local
storage.
Is
we
get
a
little
bit
of
head
start
on
trying
to
get
the
ecosystem
to
adopt
it,
which
helps
a
little
bit
to
make
async
local
storage
more
stable
as
well?
E
So
I
guess
so
we
got
to
come
up
with
the
proposal
for
like
dia
to
you
know.
Somebody
would
need
to
like
do
the
pr
to
make
async
local
storage
stable
separately,
or
we
could
just
wait
until
it's
like
we're
ready
on
the
async
local
storage
exit
criteria
too.
E
B
A
A
B
Yeah
yeah,
so
that
that
already
kind
of
reached
into
that
one
a
little
bit
a
couple
times,
but
it's
at
this
point
been
stripped
down
to
just
the
essentials.
B
It
seems
to
be
fairly
uncontroversial
at
this
point
and
got
a
bunch
of
approvals
recently,
there's
a
small
bit
of
discussion
about
putting
it
under
the
node
prefix
namespace,
which
apparently
only
exists
in
es
modules
currently,
so
that
would
require
adding
support
to
common
js
before
we
could
consider
doing
that.
B
So
I
I
left
a
comment
recently.
Just
asking
like
is
this
suggestion
blocking
this
in
any
way,
it's
not
clear
if
it
should
or.
E
E
B
Yeah
the
we've
figured
out
the
last
meeting.
I
guess
that,
or
you
know
at
the
like
after
the
tsc
meeting
recently.
That's
it
doesn't
actually
need
to
be
a
major
change.
Okay,
but
then,
like
after
that,
the
node
prefix
suggestion
came
up.
B
I
think
yeah
miles
suggested
that
and
there's
kind
of
a
bunch
of
discussion
after
that
which
was
like
this
doesn't
actually
exist
in
common
js,
yes,
and
then
like
what
would
we
have
to
do
to
make
this
existing
common
js
and
then
some
comments
that
adding
it
to
common.js
could
probably
be
considered
assembler
minor
as
well,
so
we
could
possibly
like
add
support
for
the
node
prefix
to
command.js
as
a
minor
in
15,
and
then
after
that
is
added.
Do
another
minor,
adding
diagnostics
channel.
B
Maybe
it's
there's
no
specific
comments
that
diagnosis
diagnostics
channel
should
be
blocked
by
that
so
trying
to
find
out
if
anyone
actually
thinks
it
should
be
or.
B
C
E
A
A
A
A
E
B
Yeah
there's
the
the
discussion
was
about
like
the
problematic
models.
Markdown
filed
is
not
really
great.
It
kind
of
suggests
that
these
things
are
bad,
which
is
not
ideal,
and
it's
also
not
super
actionable.
It
just
kind
of
lives
in
the.
B
Notices
it
because
not
an
issue,
so
what
we
should
be
doing
instead
is
pull
out
all
the
contacts
from
it
and
just
make
separate
issues
for
it,
pointing
to
like
yeah,
like
this
particular
module
breaks
context.
For
this
reason,
here's
some
description.
Why
and
what
needs
to
be
done
to
make
it
work
and
yeah.
Someone
just
needs
to
take
the
time
to
do
that.
D
Yeah
so
after
spent
some
time
to
to
get
the
context
of
the
outrage
execution,
it's
fair
to
say
the
only
two
for
profiling,
node.js
cross-platform
is
the
usage
of
the
profiler
start
and
profile
stop.
However,
these
dynamic
instrumentations
block
the
event
loop
because
it
needs
to
enter
it
over
all
functions
to
map.
D
D
D
A
So,
if
I
understand
correctly,
there
could
be
two
or
three
parts
to
the
problem:
one
is
to
understand
or
standardize
the
tools
and
the
best
practices
around
profiling,
diagnostics,
profiling,
based
problem.
Determination,
second,
would
be
to
find
any
gaps
in
terms
of
the
capabilities
and
implement
those
gaps,
and
the
third
one
would
be
doing
it
in
a
performance
efficient
manner.
A
Michael
correct
me,
if
I'm
wrong
or
that.
E
A
A
E
E
D
Yeah-
and
this
is
not
it's
not-
a
g
was
usage
on
the
production
environment
because
you
have
some
performance
issues.
A
F
E
E
C
E
E
E
A
Yeah,
okay,
so
so
the
deep
dive
contains
what
we
believe
is
the
existing
capability
and
what
we
believe
is
the
standard
practice
of
attacking
problems
in
the
in
the
performance
space
that
requires
profiling,
so
that
can
be
cross-verified
with
this
roadmap
and
see
how
do
they
tally?
A
What
are
the?
What
are
the
gaps,
etcetera
and
you?
You
can
review
that
you
can.
You
can
come
up
with
set
of
statements,
saying
that
you
are
not
happy
with
the
the
current
approach.
These
are
the
things
that
you
believe
are
gaps.
These
are
really
production
scenarios
and
potentially
we
can
incorporate
that
and
then
see
the
actual,
tooling
gaps.
A
Yeah,
what
I
suggest
is
once
we
get
the
google
docs.
I
will
pass
it
on
to
you.
You
can
review
the
content
of
the
google
docs
specifically
on
the
cpu
profiling
section,
in
conjunction
with
the
the
roadmap
issue,
which
is
currently
attacked
and
see
how
much
is
overlap,
how
much
is
fulfillment
and
then
we
can
remove
this
item
from
the
agenda.
You
can
create
a
fresh
issue
with
the
exact
requirement
in
the
in
the
preview
of
the
google
doc.
A
A
That
the
last
one
in
the
item
is
stable,
api
asynchronous
stable
api
tracking
issue.
B
Yes,
that's
been
open
for
like
literally
years
at
this
point
and
I'm
starting
to
wonder
if
that
even
needs
to
still
exist
on
here
with
the
like
mark
async
resource
and
async
local
storage
as
stable
stuff.
B
I'm
personally
of
the
opinion
that
asian
cox
itself
should
probably
never
be
stable,
just
expose
too
much
internals
and
things
like
that,
but
we've
kind
of
left
it
just
as
like
a
really
broad
tracking
issue.
Just
around
like
the
subject
in
general
and
like
there,
there
is
still
also
the
the
the
there.
There
is
also
like,
potentially
some
things
that
ancient
local
storage
does
not
solve.
That
async
does
solve
and.
B
If,
if
there
is
my
feeling
is
that
we
should
identify
what
those
things
are
and
make
different
apis
for
that,
and
not
do
anything
with
asynchronous
for
that,
so
I'm
not
too
sure
what
we
should
do
with
this
issue,
but
related
to
the
general
stability
of
that
category
of
things,
though,
there
is
still
a
open
pull
request
for
adding
async
context,
handling
correctly
to
an
api
which
is
number
32,
930
paste
the
link
in
the
chat.
If
anyone
wants
to
have
a
look
at
it,.
E
B
To
castle
it
got
got
it
got
an
update
about
a
week
ago
and
then
a
couple
comments
on
it.
You
you
approved
it
and
it
was
yep
some
other
small
comments,
but
it
hasn't
had
further
iterations
since
then,
but
so.
E
The
team's
radar
like
in
the
napi
team
meetings,
we've
been
touching
the
base
and
legendary
cass
said
he'd
have
some
time
to
try
and
push
it
forward.
B
E
B
Yeah
that
that,
I
think,
is
one
of
the
remaining
issues
for
having
the
general
concept
of
context
propagation
stable,
having
this
feature
in
there
having
async
resource
stable,
so
people
can
start
using
it
and
that's
pretty
much
it
that
that's
somewhat
separate
from
asynchronous
itself.
I
don't
know
if
we
want
to
have
a
discussion
about
like
what
we
should
actually
do
with
this
specific
tracking
issue.
B
If
we
still
want
to
have
that
or
if
we
want
to
like
make
another
thing,
that's
maybe
a
little
better
representative
of
what
like
what
the
current
reality
actually
is.
E
B
B
B
Like
have
substantial
changes
to
be
something
even
remotely
safe
to
be
stable,
I
think.
E
So
I
mean
maybe
making
a
comment
along
about
those
lines.
It
says
you
know
that
the
current
the
current
team's
thoughts
are
that
you
know
this
maybe
will
never
be
stable.
The
focus
is
on
you
know,
other
exposing
function.
You
know
the
required
apis
through
other
things,
like
async
local
storage.
You
know
we're
closing
this
issue
because
it's
not
there's
no
current
champion.
That
says,
let's
push
to
make
async
puck
stable
right.
B
Yeah
I
I
do
somewhat
feel,
though,
that
we
should
ultimately
have
a
goal
of
removing
the
async
hooks
api
from
like
public
exposed
interface
at
some
point
yeah,
but
I
don't
know
how
we
want
to
go
ahead
with
that,
especially
given
the
basic
local
storage
probably
doesn't
solve
everything
that
async
is
doing
right
now.
B
Okay,
I
know
node
clinic
does
some
stuff
with
it
that
basic
local
storage
doesn't
like
it
isn't
capable
of
doing
so.
We
should
try
and
figure
out
like
how
can
we
provide
what
what
these
other
modules
need
in
a
way?
That's
actually
safe.
E
E
E
You
know
the
the
future
direction
would
be
to
provide
the
required
functionality
through
additional
apis.
One
of
them
that's
already
in
play,
as
they
sync
local
storage,
but
that
doesn't
cover
everything.
So
we
would
need
to
you
know,
figure
out
what
other
additional
apis
are
needed
and
then,
finally,
the
the
plan
would
be
to
deprecate
async
hooks
right.
B
And
I'm
actually
already
working
towards
some
parts
of
that.
One
of
the
reasons
clinic
uses
asynchronous
directly
is
for
tracking
of
promise
objects
which
I
I
have
been
working
towards.
The
promisebook
api
like
about
a
year
ago,
was
all
just
c
plus
sides
couldn't
really
interact
with
it
in
any
usable
way.
At
the
like
user
facing
level,
I
added
a
javascript
fastpass
version,
so
if
you
don't
have
a
descript
destroy
hook,
then
it
uses
that
I'm
working
on
moving
all
of
it
to
javascript.
B
Part
of
that
is
adding
this
javascript
function.
Version
of
the
promise
api
to
v8,
which
I
mentioned
at
the
start
of
this
meeting
and
part
of
that,
will
be
I'm
going
to
change
the
promissor
class,
so
it
can
be
used
from
the
javascript
side
to
wrap
the
promise
objects.
B
All
of
the
logic
of
the
native
promissor
could
be
implemented
in
the
javascript
side
and
then,
when
we
get
to
that
point
eventually,
there's
the
possibility
of
actually
just
exposing
promise
hook
directly
as
a
separate
api
from
async
hooks
and
then
asynch
hooks
can
just
be
a
consumer
of
it,
and
the
design
of
promise
hook
is
a
lot
safer.
It's
just
exposing
promise
objects
so,
like
you
can
listen
to
the
response,
but
you
can't
really
mess
with
anything
it's
doing,
whereas,
like
asynchronous,
is
having
you
right
handles.
E
B
Yeah
yeah,
there's
still,
I
think,
hooks
like
also
reports
the
handles
themselves
like
there.
There
is
useful
information
to
be
gathered
from
what
async
currently
does.
So
I
think
we
need
to
identify.
A
Yeah
thanks
right,
it's
weird.
On
top
of
the
hour,
the
one
thing
which
we
wanted
to
do
couple
of
weeks
back
itself,
but
slipped
because
of
the
timing
constraints
is
to
go
through
the
deep
dive
document
the
google
docs
and
discuss
on
the
next
actions
on
that,
mostly
on
the
documentation,
basically
publication.
So
the
the
way
we
develop.
A
The
deep
dive
document
is
to
brainstorm
as
a
team
cover
the
entire
spectrum
of
use
cases
in
the
production
anomalies
and
devise
the
complete
diagnostic
story,
with
the
help
of
the
tools
and
the
methods
and
the
best
practices
in
some
places,
it's
a
complete
documentation
in
some
places
it
those
are
providing
some
hints
only
so
that
needs
some
pruning
activity,
needs
some
splitting
segregation,
cleaning,
refining
and
then
formatting
so
that
it
can
be
externally
published.
So
that's
the
overall
activity.
I
think
it's
worthwhile
to
discuss
now
in
one
sitting
itself.
A
So,
given
the
fact
that
it's
slipping
probably
we
should
start
do
that
as
a
first
item
in
the
next
week.
Next
sitting.