►
From YouTube: Node.js Diagnostics WG 2020-10-28
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
A
B
Yeah,
I'm
I'm
doing
a
rewrite
of
the
promise
hook-
api
in
v8,
so
it
currently
uses
c
plus
plus
functions
which
crosses
the
barriers
a
bunch,
so
I'm
rewriting
it
to
use
js
functions,
so
it
should
be
quite
a
bit
faster.
I've
made
some
pretty
good
progress
on
that.
I
have.
I
have
it
basically
working
as
long
as
it
doesn't
turn
on
the
optimizer,
so
just
working
on
figuring
out
how
to
get
it
to
work
with
the
optimizer.
Now.
A
A
A
A
A
major
chunk
of
work
that
is
pending
all
the
good
work
which
we
did
so
far
is
fulfilled
only
if
it
is
externally
visible
and
consumed
by
the
real
users
so
towards
that
effect,
I
think
a
discussion
we
can
have
on
the
lines
of
who
wants
to
volunteer,
for
which
section
and
what
kind
of
work
needs
to
be
carried
out
in
each
of
the
top
level
modules
or
topics
or
headers.
That
was
the
kind
of
discussion
which
I
was
hoping
to
have
today
before
any
other
items.
A
So
at
this
point,
without
mary
in
the
meeting,
we
can't
have
that
discussion,
but
without
actually
touching
the
document,
though,
the
things
which
I
believe
we
should
be
doing
is
reviewing
the
content
defined
based
on
any
changes
that
may
come
up
when
you
actually
try
out
these
tools
in
a
real
anomaly
use
case,
fill
in
any
sort
of
gaps
and
then
reformat
for
the
markdown
stuff
that
is
required
for
the
external
content
and
then
publish
that's.
The
kind
of
breakup
work
that's
required
for
each
of
this
top
level
content.
A
A
We
came
up
with
a
user
journey
on
each
of
these
use
cases
by
identifying
the
most
recommended
tool
and
traveling
from
the
actual
problem
context
to
the
resolution,
with
the
help
of
the
usage
of
the
tool,
as
well
as
the
various
best
practices
and
methodologies.
So
that's
essentially
the
deep
dive
document.
A
It
says
that,
unfortunately
I
don't
have
the
document
link
right
now
to
actually
do
a
demo
or
a
walk
through
that
on
that,
so
that
technically
the
the
work
is
complete
with
respect
to
the
scope
and
coverage.
A
It
actually
makes
sense
and
then
do
some
refinements,
for
example,
in
in
some
cases
we
would
have
returned
just
one
liner
or
a
short
form
would
need
some
expansion,
probably
with
some
screenshots
or
some
code
snippets
or
some
call
stack
tracer.
What
what
is
actually
relevant
for
the
scenario
and
then
we
would
need
to
format
it
for
the
external
publication,
most
probably
in
md
markdown
format.
C
D
A
C
A
D
E
A
A
E
A
A
A
E
And
I
guess
even
links
to
like,
because
we've
agreed
on
some
of
the
section
names
right,
because
we
did
start
writing
some
of
them
yeah
yeah.
That
seems
like
the
the
right
one,
maybe
in
the
like
the
very
first
comment
or
the
description
versus
like
another
comment
at
the
end,
so
that
when
you
go
to
it,
you
see
where
we're
at.
A
All
right,
so
I
suggest
everybody
to
have
a
look
at
this
and
for
a
friends,
please
have
a
look
at
the
documentation,
folder
to
understand
the
the
past
work
and
the
prayer
art
on
this
particular
thing.
As
soon
as
I
get
the
top
of
the
link
to
all
the
google
docs,
I
will
put
it
in
the
first
comment
of
issue
number
254
and
then
please
mark
your
name
against
any
of
the
deep
dive
which
you
are
interested
to
progress
on.
A
A
Yeah
v8
profiler
is
an
open
item
trace
even
tracing
trace.
Events
is
an
open
item.
Yeah.
It
essentially
means
that
is
a
valid
identified
user
journey
and
there
would
be
an
entry
in
one
of
the
deep
dive
documents.
A
We
just
need
to
convert
that
section
in
the
google
docs
to
a
format
that
is
visible
in
the
documentation.
Folder
of
the
repo.
E
A
B
Yeah,
nothing
new
on
that
still
just
waiting
for
a
review.
I
don't
expect
to
get
much
until
after
the
core
diagnostics
channel
stuff.
A
A
B
Yeah,
so
I
believe
we
pretty
much
came
to
the
consensus
that
async
resource
can
probably
be
stable
and
asynchronical
storage.
We
wanted
to
let
it
sit
for
a
bit
and
you
need
to
define
some
exit
criteria
which
I
haven't
really
got
around
to
yet.
A
I
have
placed
a
set
of
criteria
which
I
kind
of
collated
from
various
other
modules,
which
exited
experimental
the
last
couple
of
years.
I
just
pasted
the
comments
pertinent
to
that.
Did
you
have
a
chance
to
look
at
that?
I
I'm
not
claiming
that
this
is
100
foolproof
and
it's
100
percent,
contextual
to
the
specific
module
which
we
are
talking
about,
but
it
would
give
a
high
level
reference
or
a
ballpark
checklist.
A
B
Yep
yeah,
I
saw
the
comments
I
haven't
really
taken
the
time
yet
to
go
through
and
like
map
that
to
what
this
conceptually
means
for
ice
and
global
storage
itself,
because,
like
a
bunch
of
that
is
kind
of
high
level,
so
you
need
to
just
kind
of
go
through
and
figure
out
like
does
it
have?
This?
Is
this
relevant
in
this
case?
B
Those
sorts
of
things
just
haven't
had
the
time
to
deal
with
that.
Yet.
A
A
A
Are
the
evidence
of
this
api
or
the
feature
that
is
being
used
in
the
field,
other
frameworks
or
npm
modules,
which
are
abstracted
on
top
of
this
feature?
These
are
the
kind
of
questions
which
usually
happen,
and
then
what
is
the
ci
story
around
this
module?
Are
there
a
lot
of
flake
test
other
lot
of
tests
that
are
being
escaped?
What
is
the
overall
confidence
from
the
test
team?
B
A
A
E
E
A
Okay,
so
basically
we
define
the
checklist.
We
assert
that
these
checklists
are
met
and
then
go
with
the
pr
with
the
checklist
and
the
reviewers
agree
that
yeah.
These
are
the
right
things
to
be
checked
and
we
see
that
these
are
all
achieved
and
if
they
are
not
happy,
they
ask
the
questions.
E
E
A
regular
pr
review
at
that
point
right
with
the
reference
to
the
checklist
saying
you
know
it's
ready
to
become
non-experimental
because
of
these
reasons
people
are
always
free
to
say
well
what
about
this
or
that
or
but
in
a
lot
of
cases,
people
look
at
and
say
yeah,
okay,
that
that
was
thought
through.
That
seems
reasonable.
E
I
mean,
and
it
often
included
a
list
of
so,
for
example.
I
know
there
is
a
pr
that's
being
worked
by
lucinda
cass
to
fix
up
one
of
the
cases,
for
you
know,
context
local
storage
and
api.
So
we,
you
know,
in
the
case
of
I
think,
worker
threads.
We
had
a
list
of
three
or
four
of
those
kinds
of
things
which,
like
here,
issues
we
knew
were
existing.
We
should
check
those
off
before
we
would
propose
it
being
experimental
as
well.
E
And
you
know
in
this
case,
in
this
case
bradley
raised
a
few
issues,
so
I
think
those
issues
would
be
called
out
and
then
you
can
have
the
you
know.
We've
discussed
them
and
agreed
that
it's
okay
or
you
know,
and
that
could
be
like
and
it's
fine
the
way
it
is
or
it
could
be.
No,
we
need
to
do
something
first
or
whatever,
but
like
something
that
says
they
were
actually
addressed
in
terms
of
a
concern.
A
This
checklist
in
the
same
issue
beneath
and
for
us
to
have
a
look
at
that
and
see,
have
a
discussion
around
that
and
make
sure
we
all
agree
on
that
and
then
go
with
the
pr.
B
E
Right
I'm
just
thinking
like
has
there
been?
Is
it
due
to
discussion
that
still
needs
to
be
resolved
or
just
lack
of.
B
But
I
already
mentioned
it
in
the
tsc
issue.
Just
to
open
this
week
bring
it
up.
B
Yeah
just
get
it
getting
a
mention
of
like
yeah
that
this
is
blocked
on
tsc
reviews.
Please
have
a
look
at
this.
If
you
have
time
pretty
much
all
that's
needed.
A
B
Maybe
not
sure
it
was
mentioned
that
the
last
one.
E
Guess
the
question
is:
is
it
is
it
controversial
like?
Is
there
I'd
have
to
go
back
and
read
it
like?
If
it's
just
a,
we
should
do
this
everybody
agrees.
We
should
do
this.
We
just
need
more
reviews
than
not
necessarily
if
it's
something
where
the
tsc
needs
to
better
understand.
Why
you
know
that
kind
of
stuff.
B
E
B
It's
not
not
really
any
like
controversy
in
the
pr.
It's
got
like
several
approvals,
and
everyone
seems
to
be
basically
positive
about
it.
At
this
point
there
was
some
like
earlier
controversy,
just
with
some
of
the
other
components,
which
is
why
I
pulled
them
out
the
casing.
Caterable
and
the
span
api
right.
The
current
stuff
seems
to
be
uncontroversial.
B
The
the
only
stuff
that
was
never
entirely
resolved
was
some
comments
from
james
and
like
really
really
early
in
the
pr
about
just
naming
of
things,
he
made
some
comments
that,
like
the
module,
could
maybe
be
called
like
dagnon
or
diagnostic
hooks,
instead
to
fit
with
the
other
like
perfux
and
basic
hooks
naming,
but
then
like
never
responded
since
then,.
B
Yeah
so
like
a
mary
brought
up
this
according
to
our
process,
top
level
modules
needs
tse
approval
yeah,
so
that
I
I
do
have
like
the
na
the
name
space
was
already
taken
by
me
in
npm,
so
it's
not
like
clobbering
someone
else's
module
or
anything.
B
E
E
E
I
think
my
take
will
kind
of
be
like
I'll
go
ahead
and
approve
it.
Unless
somebody
is
saying
there's
a
reason
not
to,
and
we
need
how
many
approvals
right
we
need,
I
guess
right
now,
yeah
we
have.
D
B
Yeah
there's
been
a
couple
different
discussions
around
like
creating
some
sort
of
like
experimental
name,
spacing
thing
near
the
end
of
that
issue.
There
was
another
discussion
about
there's
now,
like
the
node
prefix
thing,
I'm
just
talking
about
putting
that
behind
the
node
prefix,
but
that
only
works,
and
he
has
modules
currently
so
need
to
be
added
to
common
js,
and
it
seems
that
we
decided
adding
that
feature
to
common
js
shouldn't
block
this
right.
Yeah,
okay,
makes
sense.
A
But
not
sure
whether
the
pr
completely
addresses
the
actual
concern.
A
So
the
question
is:
is
that
completely
achieved
by
reviewing
the
pr
35498?
I'm
not
sure
that
is
actually
addressing
the
same
concern
as
it
is.
So
I
guess,
unless
somebody
else
have
a
better
insight,
we
will.
B
A
On
the
other
hand,
as
the
team
or
as
the
working
group,
it's
worthwhile
to
ask
among
ourselves
whether
I
mean
this
level
of
requirement
is
it?
Is
it
anywhere
featuring
in
our
production
pain
points?
A
B
Yeah,
so
I
opened
that
last
time
like
after
the
last
meeting,
just
because,
like
the
the
later
issue,
the
basement,
stable,
api
tracking
issue
has
been
in
the
like
in
the
agenda
for
probably
literally
over
a
year
now
and
seems
to
be
the
consensus
that
facing
hooks,
at
least
in
its
current
form,
is
probably
never
going
to
be
stable.
So
we're
trying
to
identify
like
what
are
the
things
other
than
async
local
storage,
that
we
can
layer
over
top
of
ace
and
cooks
to
make
a's
and
cooks
itself
ireland.
B
B
How
can
we
like
distill,
that
down
to
some
api
ideas,
new
ways
that
we
can
interface
with
these
parts
of
the
system
to
present
an
api?
That's
a
little
more
useful
for
the
particular
purposes
and
safer.
B
Comments
in
there
and
so
far
come
up
with
these
cases.
They're
like
we
need
long
stack,
traces
for
various
purposes,
so
we
need
to
be
able
to
have
a
way
to
like
get
the
init
event,
at
least
to
gather
that
there's,
like
tracking
handle
life
cycle,
trying
to
identify
if
we
need
direct
access
to
the
resource
object
or
if
it's
sufficient.
Just
having
the
type
and
another
use
case,
was
measuring
time
spent
in
blocking
code
so
being
able
to
like
store
a
timestamp.
B
So
it
it's
so
far
seems
like
the
net
is
at
least
required,
at
least
at
a
like
more
higher
level
than
exists
right
now
for
the
purpose
of
like
getting
the
type
and
like
storing
timestamps
and
things
like
that,
the
later
things
could
maybe
be
internalized
more.
It's
like
if
we
had
an
api
there's
like
whenever
and
it
happens,
we
can
like
stick
a
time
stamp
on
like
say,
like
this
resource
should
be
using
the
timestamp.
B
We
could
have
like
an
api
that,
like
we
currently
have
like
execution
async
resource,
we
could
have
something
that's
like
like
set
timestamp
for
this
resource
id
and
then
like
whenever
it
does
the
like
internal
bits
of
acing
hooks.
Currently,
it
could
like
create
the
like
it's
processing,
hr
time
timings
from
the
group
time.
E
B
Not
candidates
for
the
diagnostics
channel
yeah,
but
potentially
I
I
I
think,
the
like
measuring
time
spent
in
blocking
codes.
B
Just
because
you
want
like
a
more
complete
measurement
of
like
the
whole
system,
I
don't
think
that
fully
parts
over
like
a
lot
of
use
cases
like
you
could
measure
like.
I
want
to
know
how
long
the
request
took,
but
if
you
want
to
know
like
the
overall
timing
of
like
the
whole
process,
diagnostics
channel,
I
don't
think
should
be
reporting
like
every
single.
B
A
little
bit
more
high
level,
so
yeah
the
measuring
time
spent
in
blocking
code
you're
going
to
be
like
putting
that
in,
like
I
want
to
just
measure.
Every
single
async
barrier,
basically
and
diagnostics
channel,
doesn't
want
to
concern
itself
with
facing
barriers.
It's
just
here's.
An
interesting
thing
that
happened
like
an
fs
read
happened,
so
my
sequel,
query
happened
could
have
been
like
100
other
things
in
the
middle
there
that
didn't
matter,
but
this
might
be
relevant.
B
And
then
yeah
tracking
handle
life
cycles.
Same
kind
of
thing,
you
want
to
know
a
more
complete
picture
of
exactly
what
things
are
being
held
open.
B
E
D
B
D
B
So
if
we
could
just
not
expose
the
resource
anymore,
just
deprecate
that
as
an
argument,
then
I
think
that
would
be
fine,
but
I
guess
it's
also
still
slightly
clumsy
api,
possibly
so
if
we,
if
we
do
narrow
down
like
what
are
the
actual
use
cases
for
this,
then
we
might
be
able
to
come
up
with
apis
that
are
just
better
for
the
needs
of
our
users.
B
B
Any
more
use
cases
we
can
add
to
this
would
help
if
you
know,
like
anyone,
that's
doing
like
obscure
stuff
with
asian
hooks.
B
E
I
think
actually,
like
even
writing
a
blog
post,
which
we
would
have
posted
to
the
node.js
foundation
medium.
So,
like
a
blog
post
that
says,
we've
gotten
some
external
input
here,
the
use
cases
that
we've
already
gotten,
you
know
we're
looking
at
how
we
can
how
we
can
tweak
it
or
change
it
or
replace
it
to
get
to
something
that
won't
be
experimental,
give
us
your
feedback
and
then
tweeting
that
it
would
probably
make
the
most
sense.
E
D
B
Yeah,
so
mary
was
basically
going
to
go
through
that
existing
file
and
break
it
up
into
separate
issues
for
like
each
module
so
like.
We
have
like
actual
issues
to
keep
track
of
this,
rather
than
some
file
that
everyone
forgets
exists
and
we
can
like
separate
it
into
issues
per
per
module.
B
C
A
B
B
No,
no
sorry
we're
at
the
asian
cooks
thing
now:
yep
yeah,
that's
at
number
437!
I
guess
is
kind
of
meant
to
replace
this
issue
somewhat.
So
I
don't
know
if
there's
anything
else
that
still
needs
to
be
said
for
this
one
but
yeah.
B
I'm
of
the
opinion
that
facing
hooks
as
it
is,
should
never
be
stable.
So
we
need
to
find
a
path
to
either
making
the
changes
to
make
it
stable
or
replacing
with
something
else
that
can
be
stable.
D
E
B
Okay,
yeah,
I'm
I'm
somewhat
of
the
opinion
that
asian
cooks,
as
it
is
designed
right
now,
was
somewhat
built
with,
like
a
huge
list
of
like
many
possible
use,
cases
in
mind
and
it
kind
of
makes
it
just
mediocre
and
everything.
B
So
if
we
just
like
put
a
little
more
thought
into
like
gathering
feedback
from
the
community,
you
can
do
like
what
exactly
are
you
doing
with
this?
And
how
can
we
do
this?
For
you
better?
B
We
could
just
deliver
more
purpose-focused
apis
that,
hopefully,
like
don't
have
nearly
the
performance
impact
that
jason
cooks
does
and
like
would
just
be
a
lot
friendlier
to
work
with
than
like
async
hooks
which,
like
for
most
of
what
I've
seen
people
use
async
hooks
for
it's
pretty
awkward
to
work
with,
like
quite
failure.
B
Problem,
there's
lots
of
like
weird
edge
cases
and
like
event
ordering
and
just
like
certain
things,
won't
emit
certain
events
in
certain
cases,
and
you
have
to
be
aware
that
that's
a
possibility-
and
it's
just
it's
really
difficult
for
people
to
deal
with
safely,
sometimes
so
yeah
just
having
something
that
actually
does.
What
what
you
really
need
would
be
better,
I
think.
E
B
Yeah,
like
I,
I
think,
like
the
majority
of
like
the
likes.
Certainly
the
c
plus
plus
stuff
would
probably
remain
pretty
much
as
it
is
right
now,
just
because,
like
it
is
currently
being
used
by
asynchronous
storage
and
async,
local
storage
will
continue
to
need
just
like
a
bunch
of
the
same
things
there's
like
so.
Some
of
the
c
plus
plus
stuff
currently
is
like
not
used
there,
but
it
might
be
used
in
other
places.
So
I
expect
mostly
that
will
remain
the
same.
B
The
javascript
side
of
it
might
change
a
bit
as
needs
evolve.
B
Yeah
there's,
like
the
the
javascript
side
of
it,
does
like
a
whole
bunch
of
somewhat
complicated
stuff
to
try
and
massage
this,
like
one
c
plus
plus
interface,
into
like
multi-tenant
javascript
interface
and
there's
like
a
lot
of
weird
performance,
hackery
to
try
and
like
synchronize
between
the
two
sides
efficiently,
and
it's
not
really.
A
A
If
not,
that's
the
end
of
today's
discussion,
I'm
going
to
hunt
for
the
google
docs
for
the
deep
dive
user
journeys
and
make
the
issue
number
254
populated
with
the
information
about
the
user
journey
links
as
well
as
the
the
table
where
you
can
have
a
review
on
the
items
and
whichever
items
you
are
interested,
you
can
register
yourself
or
put
your
name
against,
and
we
can
kick
start
that
work
probably
should
target
to
complete
in
the
coming
couple
of
months
itself
and
just
putting
some
realistic
targets
so
that
we
we
make
some
progress
on.