►
From YouTube: 2020-07-29 Diagnostics Deep Dive 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
A
B
B
B
B
Today
we
are
going
to
be
driving
those
use
cases
in
a
user
journey
manner,
so
we
will
be
talking
about
for
each
use
case.
We
are
going
to
be
talking
about
how
to
understand
that
this
is
the
use
case
that
user
is
seeing
and
what
are
the
steps
to
that
leads
to
the
correct
tool
to
investigate
the
use
case.
C
A
A
B
But
like
when
v8
is
still
on
the
interpreters
tab,
you
can
see
the
byte
code,
but
once
it's
compiled
down
to
mission
code,
I
don't
think
there's
any
flags
that
can
be
used
to
to
look
at
that,
although
it
can
be
still
accessible
via
apis.
B
So
it's
a
bit
tricky,
but
both
are
possible.
What
we
don't
have,
at
least
I
don't
think
we
have-
is
a
mapping
between
bytecode
animation
code.
I
don't
think
I've
ever
seen
this
too
for
v8
this
would
be
similar
to
a
source
map,
and
I
don't
remember
seeing
it,
although
that
doesn't
mean
it
doesn't
exist.
A
B
I'd
go
one
step
back
and
ask
one
step
back
and
ask:
are
jit
compa?
I
should
misbehave
common
issues.
I'd
expect
the
scenario
to
be
more
about
a
developer
horse
in
the
function
than
on
the
v8
side.
B
Yeah
I'm
asking
because
that's
not
an
issue
that
I
came
across
before
I
came
across
problems
with
v8
and
performance
and
v8
and
memory
usage,
but
not
misbehavior,
or
the
function
being
compiled
just
being
just
not
reflecting
your
javascript
code,
those
things
they
never
seen
again.
That
doesn't
mean
it
didn't
happen.
C
Yeah,
usually,
this
type
of
scenarios
are
very
rare
compared
to
the
exceptions
and
crashes,
but
given
the
premise
of
this
deep
dive
and
documentation
is
to
cover
the
user
journeys
which
are
possible
and
given
the
fact
that,
for
this
particular
user
journey,
we
should
have
at
least
laid
out
the
plan
for
problem
determination.
Even
though
it's
a
different
matter
whether
the
end
user
is
able
to
follow
that,
I
mean
he
is
interested
to
do
the
complete
problem,
determination
steps.
B
Yeah,
I
agree
I'm
just
thinking
that,
when
we're
laying
out
these
steps.
B
A
A
B
C
B
C
B
As
jit
code
instead
of
interpreted-
and
that's
probably
else
worth
noting
it's
not
this
one
but
skip
the
interpretation.
B
B
B
B
B
The
flags
that
print
out
the
byte
code
for
functions
or
how
to
read
the
memory
to
check
for
the
major
mission
code,
or
should
we
just
advise
users
to
open
a
ticket
to
v8.
In
that
case,.
A
That
would
kind
of
be
my
take
is
that
it
takes
a
whole
other
level
to
look
at
the
byte
code
and
this
and
the
machine
code
to
figure
out
what's
going
on,
but
if
you
can
ex,
if
you
can
basically
take
it
down
to
this
method's
compiled,
I
end
up
with
what
I
don't
expect
it's
not
compiled.
I
ended,
but
I
do
end
up
what
I
expect.
That
should
be
enough
to
open
an.
A
B
B
Doesn't
do
any
compilation
of
javascript
nor
any
transformation
it
kind
of
does,
but
when
requiring,
we
wrap
it
in
a
function,
but
that's
the
extent
of
it
other
than
that.
Node.Js
doesn't
do
any
transformation
on
the
code
and
it
definitely
doesn't
do
any
compilation.
So
if
it's
a
compilation
issue,
it's
definitely
a
v8
issue.
It
can
be
a
node.js
issue
when
the
user
is
calling
apis
and
the
apis
are
returning
wrong
values,
but
that
should
be
covered
in
a
scenario
that
is
previous
to
this
one.
I
think.
D
B
Personally,
I
usually
first
look
at
the
user
code
to
see
the
user
slash
application
code
to
see
if
the
function
has
a
logic
outline
correctly.
If
it
doesn't
have
and
look
at
library,
api
calls
to
see
if
they
are
returning
the
expected
value.
If
they
are,
I
look
at
node.js
if
they,
if
node.js
is
returning
correctly
I'd,
look
at
v8.
B
B
B
I
just
said:
does
anyone
think
of
any
other
scenarios
for
computation
misbehavior?
B
So
can
we
start
discussing
how
to
identifying
logic
on
user
code
and
then
once
we
cover
that
if
the
user
doesn't
identify
anything
wrong?
That
means
the
next
step
can
be
the
problem
and
then
the
next
one,
the
next
one
does
everyone
agree
with
that.
D
B
Yeah
I
do
that
as
well
a
lot
I
usually
start
preventing
functions
because,
most
of
the
time
in
the
debugging
code,
it's
not
my
code,
I'm
on
a
support
team
at
netflix,
basically
for
other
teams.
B
So
I
read
more
other
codes
than
I
write
my
own.
This
is
just
why
I
end
up
reading
functions
a
lot
instead
of
starting
by
adding
breakpoints
but
yeah
when
I'm
working
on
my
own
code
bases,
I
usually
start
by.
D
B
B
B
A
So
it
might
be,
you
know
we
might
say
if
you
can
run
the
code
locally,
do
that
and
use
the
debugger.
Otherwise
you
know
in
production,
you're
likely
going
to
have
to
use
traces
console
logs,
whatever
right
like.
In
fact,
if
there's
any
trace,
you
can
turn
on.
That
might
be
the
the
easiest
versus
like
console
logs.
You
need
to
change
the
code
right
and
actually
changing
the
code,
and
redeploying
is
not
necessarily
that
straightforward.
A
A
You
have
any
right
turning
on
tracing
right
like
if
there's
trace
points
built
in
to
your
application
or
to
your
you
know,
or
the
runtime
turning
those
on
can
give
you
more
information
about
the
control
flow
right.
B
The
application
trace
points.
Yes,
I
don't
think
we
have
enough
on
node.js
and
v8
for
it
to
be
useful
in
production,
although
I
might
be
wrong.
A
B
Yeah,
I
think
they,
the
v8
ones
they
they're
like
for
optimization.
The
optimization
gc
runs
that
kind
of
thing
and
not
for
which
functions
are
being.
B
I
think
maybe
you
can
use
inspector
to
attach
to
the
the
inspector
protocol,
not
the
debugger,
don't
attach
to
specific
functions,
so
they
run,
for
example,
a
console
logger
every
time
they
run,
but
I'm
not
entirely
sure
if
that's
actually
possible.
I
never
tried,
and
I
don't
remember
which
inspector
domain
is
used
if
it
uses
the
debugger
domain,
it's
not
feasible
for
production
because
it
disables
a
lot
of
optimizations
on
v8
and
makes
things
like
two
times
slower
or
more,
depending
on
the
right
situation.
A
B
Yeah
and
even
if
it's
on,
if
it's
not
a
native
code,
if
it's
javascript,
you
can't
change
it
to
add
console
logs,
for
example,.
A
B
A
B
D
C
C
B
Yeah
I'd,
imagine
it's
sorry.
I
imagine
it's
easier
to
come
up
with
a
reproducible
for
context,
insensitive
code
than
for
context
sensitive,
since,
usually
you
have
all
the
contacts
you
need
for
this.
First,
one
on
the
function
or
it's
at
least
traceable
throughout
the
application
area.
D
B
B
Do
you
have
any
tips
to
find
reproducibles?
I
always
have
trouble
helping
users
when
they
have
an
issue,
but
don't
have
an
ever
produced
bow.
I
always
have
trouble
giving
tips
for
them
to
to
write
something.
A
I
guess
I
would
I
would
if
you
start
with
the
main
use
case,
it's
like
how
do
you
cut
out
portions
of
the
code
you
know
like
you
could
buy.
You
know
maybe
like
bisection,
that
kind
of
thing
like.
Basically,
if
you
can
say
it's
cut
the
code
in
half
and
it
still
happens
and
then
cut
it
in
half
again
sort
of
sort
of
work
inwards
towards
the
smallest
piece,
where
you
still
see
the.
A
A
Yeah,
the
the
very
first
thing
is
to
try,
and
even
before
that
is
like
how
do
you
make
it
reproducible
which
comes
to
just
what
you
said
right
like
if
you,
if
you
have
to
wait
for
an
hour
for
it
to
happen
it's
much
harder
to
debug
than
if
you
can
figure
out
how
to
make
it
happen?
Whenever
you
want
right.
A
A
B
Right,
we
should
probably
give
tips
for
the
user
on
how
to
identify
intermittent
issues,
even
though
there
is
no
silver
bullet
to
identify
those.
If
there
was
we
couldn't
have
a
flight
pass.
A
I
mean
you
probably
know
if
it's
intermittent
in
that,
like
it
happens,
occasionally
like
it
doesn't
happen
every
time
a
particular
piece
of
code
runs
but
like
if
you
get
an
issue
that
happens
once
every
couple
hours
in
my
the
first
thing,
I'd
want
to
do
is
figure
out
what
code
was
running
when
that
happened.
If
I
have,
you
know,
20
30
different
requests
that
can
come
in.
Is
there
a
correlation
to
the
request
that
came
in
right.
A
A
It
triggered
the
bug
that
was
causing
us
grief
so
like
looking
at
those
you
know
if
we
can
narrow
it
down
to
like
yeah,
okay,
I
was
I
was
running
this
particular
request
and
here
my
parameters,
even
just
looking
at
the
parameters
for
a
number
of
different,
failed
ones
and
seeing
if
there's
any
correlation
between
them
can
help
you
try
and
recreate
it
or
understand.
What's
going
on.
B
B
I
think
those
are
good
tips
for
the
narrowing
down
intermittent
issues
and
making
them
more
consistent.
Yeah.
A
D
Else
really,
I
I
say
hardware,
not
header,.
D
Like
I
o,
I
operations
how
much
you
know
your
record
is
running
at
the
user's
space
or
like
that.
I
don't
know
if
it
makes
sense
to
do
I
easily
repo
reproductively,
but
can
be
good.
B
B
Yeah,
I
think
the
more
overall
idea
is
comparing
our
environments
and
seeing,
if
there's
a
difference
that
can
be
leading
to
the
intermittent
issue,
so
it
could
be.
For
example,
dependencies
some
version
might
be
different
from
other
services,
not
only
npm
dependencies,
but
factors
installed
on
the
operating
system
level.
The
kernel
might
be
slightly
different.
The
hardware
the
cpu
might
be
on
a
different
version,
so
comparing
hardware,
metrics
and
overall
environment.
D
B
A
B
B
Like
how,
how
can
I
I
have
an
application
running?
How
can
I
collect
the
parameters
that
are
being
passed
to
a
specific
function?
Do
I
need
to
restart
my
application
with
some
library
loaded
that
will
gather
the
information?
Is
there
something
that
I
can
start
at
runtime?
Is
there
some
flag
on
node.js
that
I
can
use.
A
Right
or
or
in
that
case
I
was
thinking
of
like
if
you've
got
web
requests
coming
in,
you
can
look
at
the
differences
in
you
know
what
the
parameters
that
were
requested
in
the
in
the
the
say,
the
api,
the
rest
request,
or
something
like
that.
But
it
is
a
pretty
broad,
like
there's
a
lot
of
different
levels
that
this
could
be
done
at.
B
A
B
B
B
B
B
We
classified
it,
it
has
a
different
use
case,
but
we
also
mentioned
that
it
could
be
a
initial
question.
Sorry.
D
A
Related,
actually,
that's
a
very
first
like
I
know
somebody
reported
recently
a
change
in
the
intel
behavior
and
it's
like
it
was
like
hey
after
upgrading
to
this
version.
It
was
like
okay,
then
we
could
look
at
the
change
log
and
then
from
the
change
log.
We
could
say:
okay
yeah,
you
know
we
did
make
a
change
to
icu
and
then
it
was
like,
oh,
but
that
was
planned.
B
I
agree:
that's
a
good
starting
point
just
going
back
here
quickly
on
the
checking
the
environment
specific
specifications,
but
this
could
probably
fall
there
as
well.
B
D
B
This
might
be
a
good
idea,
so
for
starters,
if
the
er
started
recently
look
for
changes
in
node.js
version
dependencies
or
any
changes
to
the
app.
B
B
B
And
for
those
we
have
some
tips
on
how
to
make
the
report
smaller,
starting
by
transferring
the
code
locally.
B
If
the,
if
the
execution
time
is
long,
try
to
make
it
smaller,
we
didn't
give
any
tips
on
this.
One.
B
B
Once
the
execution
time
is
as
low
as
you
can
get,
and
you
get
the
issue
to
happen
as
frequently
as
you
can
get
perfectly
all
the
time
use
the
steps
we
listed
in
the
first
example
to
narrow
that
narrow
down
the
code
and
create
as
small
as
possible
reproducible,
and
for
that
the
user
can
cut
everything.
B
From
the
first
point
where
the
issue
is
identified,
which
is
usually
an
node.js
api
call,
and
then
before
that
code,
the
user
can
apply
a
beside
bisecting
to
identify
which
parts
of
the
code
impact
the
results
of
the
api
call
after
bisecting
everything,
the
user
should
have
the
minimal
reproducible
and
then
they
can
open
a
issue.
On.Js.
B
B
B
B
I
think
we
have
a
good
start
on
this
user
journey.
Yep
yeah.
We
can
continue
next
in
two
weeks
discussing
library
code
and
how
to
identify
and
best
practices
to
report
library
called
issues.