►
From YouTube: 2020-07-09 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
A
A
A
A
A
A
C
We
should
probably
refer
to
the
things
that
427
is
recording
as
exceptions
and
not
errors,
and
it's
just
kind
of
a
way
to
report
that
an
exception
has
happened.
An
error
is
a
little
bit
more
subtle.
An
exception
could
be
an
error.
It
really
depends
on
the
application
a
little
bit
more
so
I
I
kind
of
made
a
another
draft
of
427,
which
is
currently
not
up
I,
could
go
link
in
actually.
A
C
C
C
We
talked
about
being
kind
of
not
really
tied
to
an
error
or
an
exception,
so
I
should
be
kind
of
unqualified
yeah,
and
the
other
thing
was
that
it
was
a.
It
was
previously
an
array
of
strings
change
that
to
just
be
a
string
and
then
add
in
log
back
severity
as
a
as
a
convention,
and
the
severity
can
kind
of
help
you
determine.
If
this
exception
was,
was
an
error
or
not.
C
So
that
was
kind
of
the
state
of
the
world,
I
wasn't
sure
if
this
would
be
enough
to
appease
more
people,
it
seemed
like
there
was
a
lot
more
traffic
on
spec
PR
427
and
it
seemed
like
there's.
Definitely
some
of
the
people
who
are
in
the
camp
where
they
would
like
to
see
more
structure,
structured
back
traces.
Commenting
there
great.
B
C
A
Think
it's
reasonable
to
to
say:
there's
a
how
do
I
put
it
the
the
the
more
you
can
expect
what
the
value
is
inside
of
a
convention
the
better
to
convert
the
more
helpful.
The
convention
is
right,
like
a
convention
where
the
value
is
in
some
totally
unknown
format
and
you're
gonna
have
to
sniff
it.
You
know
that's
less
helpful
than
a
format
where
you
know
it's
a
new
line,
separated
or
whatever
so
I
do.
Think
something
like
this.
Where
for
each
language
like
what
actually
goes
in,
that
field
should
be
defined.
A
F
A
I
wonder
if
we
can
help
when
I
think
about
this
I'm
thinking
more
about
like
the
people
who
write
a
lot
of
the
instrumentation,
we're
like
plug-in
authors,
but
I
definitely
think
every
language
API
should
probably
provide
a
helper
function
for
this
right,
like
like
every
end
user.
To
your
point,
you
shouldn't
be
asking
the
end
user
to
figure
out
how
to
get
the
stack,
trace
and
format
it
and
put
it
into
this
thing.
They
should
just
call
a
helper
function
of
some
kind
up.
B
B
F
When
I
think
about
what
sort
of
downstream
tools
are
going
to
end
up
doing
with
the
stack
trace,
it
seems
like
they
can
say,
we
support
like
various
combinations
of
things,
but
having
one
representation
that
is
sort
of
guaranteed
to
work
and
then
trying
to
provide
additional
coverage.
Maybe
is
helpful,
so
yeah
since
I
guess
would
be
having
either
a
very
for
structured
case
or
a
very
sort
of
like
open-ended.
G
H
D
A
That's
hard
to
say,
but
presuming
we
know
what
like
language
and
language
version,
assuming
that
information
is
always
available
when
you're.
Looking
at
this
information
and
assuming
that
for
each
language
and
language
version,
there's
a
format
that
it
should
be
in.
You
can't
guarantee
it
because
it's
just
a
string,
but
you
we
have
a
hint
as
to
what
it
should
be
assuming
they
use
the
helpers
yeah
and.
A
And
I've
also
wondered
about
language
specific
fields.
Right,
like
you
can
say,
for
every
language
you
get
like
something
like
a
stack
trace,
but
some
languages
may
provide
cheaply
some
additional
diagnostic
information,
that's
kind
of
language
specific
and
would
be
hard
to
capture
the
generic
field.
H
The
other
thing
that
I
found
was
really
important
as
I
work
with
it
is,
is
generate
and
a
fingerprint
on
both
the
like.
The
exception
is
being
thrown
from
a
particular
line
and
then
the
particular
exception,
as
you
find
so
many
applications
it
like
you
know,
there's
some
library
in
there
that
throws
throw
throws
and
air,
and
then
it
gets
caught
by
the
next
library
up
and
then
the
application
developer
catches
that
and
get
caught
by
the
next
library
up.
H
So
you
might
end
up
with
the
number
one
the
exact
same
exception,
getting
reported
multiple
times,
so
you
could
screen
that
out.
If
you
have
a
fingerprint
on
it
and
then
even
more
heinous,
is
you
know
if,
if
you
got
some
bug
in
there,
that's
causing
an
exception
to
get
thrown
every
time
it
you
hit
a
certain
point
in
the
code
I
mean
you
could
end
up
with
a
million.
You
know
reports
on
you
know
from
different
requests,
but
you
know
the
exact
same.
H
It's
the
exact
same
bug,
that's
causing
a
million
different
exceptions,
so
you
need
a
way
to
screen
that
out
too.
So
you
need.
You
basically
need
two
fingerprints
one
for
you
no
exception
thrown
on
this
line
and
then
for
the
individual
exception
thrown,
so
you
can,
or
else
you're
just
gonna
get
overwhelm
with
a
data
in
certain
cases.
A
So
there's
like
maybe
this
separate
issue
just
to
to
pull
it
out,
make
sure
I
understand.
It
is
like
there's
the
format
that
this
stuff
is
coming
in
and
then
there's
another
issue,
which
is,
we
may
be
automatically
capturing
the
same
exception
in
some
languages
as
the
exception
bubbles
up.
Is
it
going
to
be
a
problem
in
open
telemetry
that
that
same
exception
will
just
get
logged
over
and
over
again
as
it
bubbles
up
right.
H
Yeah
yeah
yeah
and
probably
the
biggest
you
know
besides
just
just
information
pollution
I
mean
think
of
a
case
where
you
know
I
released
some
buggy
code.
Let's
use
Java,
for
example,
that's
thrown
a
nullpointerexception
for
some
point
in
a
very
you
know,
every
time
it
hits
a
point
in
in
code,
that's
very
well
traveled!
H
So
all
of
a
sudden,
you
know
I've
been
running
this
app
for
years
and
no
issues
now
all
of
a
sudden
I'm
getting
you
know
millions
of
these
exception
reports,
and
so
now
I
just
overwhelmed
my
monitoring,
a
whole
monitoring
system,
because
I've
never
seen
this
kind
of
volume
before
and
so
now,
I
start
bringing
down
my
whole
system.
Just
because
of
this
one
little
nullpointerexception
that
got
introduced
in
the
code
somewhere.
It's
so
yeah.
I
H
B
A
A
B
So
what
what
does
it
solve
for
me?
Is
you
you,
you
propose
to
write
into
the
spec
the
requirement
that
all
collectors
I
mean
all
all
producers
order
of
of
all
Streisand
information
they
have
to
like
somehow
decide
when
to
throw
away
the
message
and
replace
that
with
only
that
fingerprint,
so
I
would
not
want
to
further
towards
all
implementation
to
implement
that
performance
optimization
inside
in
some
way,
and
so,
if
how
well
yeah.
B
F
I
ask
a
really
like
naive
kind
of
high
level
question
apologize
because
I
came
into
the
conversation.
Sort
of
late
is
the
intent
for
errors
that
were
attaching
our
information
to
spans
or
that
we're
allowing
customers
users
to
report
individual
errors
as
an
independent
sort
of
stream
of
data
yeah.
Maybe.
A
We
should
do
an
overview.
Actually,
we've
got
some
new
people
in
this
group
today
we
should
do
a
random
intros
and
a
quick
overview
of
what
what
the
hell
it
is,
we're
trying
to
solve.
Yeah.
Let
me
start
by
answering
your
your
question.
I.
Think,
there's,
there's
then,
to
to
conundrums
in
general
that
we're
looking
at
one
is
is
just
how
do
you
record
an
exception
as
an
event?
A
So,
right
now
we
don't
have
like
full-on
logging
in
open
telemetry,
but
we
do
have
span
events,
so
you
can
record
individual
events
which
is
basically
locking,
and
so,
if
an
exception
happens,
you
want
to
record
it
as
an
event
and
what
should
the
format
be
for
recording
that
exception,
so
that
that's
just
problem
number
one,
which
is
these
like?
What
are
the
semantics
for
describing
exceptions,
which
is
slightly
tricky,
because
every
language
is
a
little
different?
A
The
other
issue,
that's
also
tricky,
is
how
do
you
indicate
that
a
span
is
in
an
error
stage?
So
there's
there's
like
recording
that
an
exception
happened
and
then
there's
saying
like
this
operation
has
gotten
wrong
like
this
is
wrong
and
I
need
to
like
set
the
status
code
on
this
or
otherwise
indicate
this
fan
operation
is
in
an
unexpected
or
error,
'fl
state
and
that's
important,
because
a
lot
of
these
sampling
systems
that
are
more
advanced
than
just
coin
coin,
flip
systems.
F
A
In
order
to
do
that
cheaply,
there
of
course
has
to
be
some
way
for
whoever's
writing
the
instrumentation
or
the
end
user
to
be
like
this
is
weird
you
should
you
should
record
the
span
like
you
should
log
this
and
that's
where
it
actually
gets
more
nebulous,
because
it's
like
which
it's
one
thing
to
be
like
we're.
Recording
HTTP
status
codes
is
another
thing
to
make
the
judgment
that,
like
this
status
code,
represents
an
error.
I
think
that's
actually
a
trickier
conversation.
Are
we
talking
about
those?
Yes,
so.
A
Current
conversation
is
just
like
if
an
exception
happens
forget
about
like
earful
States
on
the
span
or
anything
like
that,
like
just
how
do
we
write
that
information
down?
You
know
so
that
the
end
user
can
do
something
useful
with
it
when
they
read
it,
so
that
that's
what
what
Matt's
proposing
right
now
and
I
think
Kevin's
had
a
hotel
on
this
in
the
past.
So
that's
what
we're
currently
discussing,
but
there
is
this
other
issue
of,
like
besides
exceptions,
how
do
you
indicate
something's
in
error?
B
So
I
think
that
Kevin's
idea
a
proposal
requirement
about
fingerprint
is
in
fact,
in
fact,
very
good.
My
my
er,
my
main
objection
is
that
I
don't
think
it
should
block
the
current
the
current
issue
of
having
some
structure
of
exception
recording
inspect,
because
if
we
have
a
currently
have
that
stacktrace
field
as
an
optional
attribute
does
not
know,
then
we
can
end
later
as
a
separate
step
that
film,
a
fingerprint
preprinting
as
a
one
more
attribute
most
of
attribute
as
well,
and
then
it
may
be
up
to
and
become
the
recommend.
B
Don't
don't
flood
with
the
same
exception
start
usually
using
fingerprinting
functionality,
but
in
my
opinion
they
should
be.
They
can
be
separate,
so
we
can't
go
forward
with
current
proposal.
We
should
last
give
us
a
structure
of
the
of
the
exception
events
on
the
spans
and
then
as
a
separate
step,
good
step,
but
a
separate
self
introduce
fingerprinting
as
a
performance
of
simulation.
F
My
sense
is
that
that
sort
of
fingerprinting
can
be
a
lot
of
the
secret
sauce
for
how
systems
kind
of
aggregate
things
and
it
maybe,
on
the
one
hand,
difficult
to
do
well
on
the
client-side
and
maybe
something
that
a
system
wants
to
do
again
later.
So
it's
not
part
of
the
core
of
what
what's
being
reported,
but
it
can
be
a
meaningful
annotation
later,
like
I,
said
not
part
of
the
MVP,
because
I
could.
A
A
H
A
H
A
How
you
calculated
yeah
yeah,
the
big
blocker
right
now,
is
we're
trying
to
right
instrumentation
right,
so
we've
got
to
the
point
where
the
tracing
systems
work
in
all
these
different
languages
and
we're
trying
to
add.
You
know
spring
support
and
django
support
and
rails
support,
and
all
of
that
and
the
lack
of
like
a
definition
for
recording
exceptions,
is
like
right
now,
like
probably
the
biggest
pain
point.
In
writing
those
exceptions
yeah
if.
H
A
A
It
turns
out
that
we
really
need
way
more
structure
than
what
Matt's
proposing
I
think
it's
always
possible
to
come
up.
I
mean
we
don't
want
to
do
this
yet,
but
we
can
always
come
up
with
a
v2
convention
later
right.
We
wouldn't
use
the
same
keys,
but
if
it
does
turn
out
in
practice
later
that
we
want,
you
know
way
more
structure,
we
could
add
some
more
field
optional
fields
for
providing
that
or
something,
but
it
doesn't
seem
like.
We
need
that
right
now.
What
we
need
is
like
this
basic
thing.
A
B
B
A
What
we
could
do
once
we
get
this
exception
stuff
in
is
I,
would
say
rather
than
doing
fingerprint
in
every
language.
That's
a
thing
we
could
model
in
the
collector
the
collectors
a
good
place
actually
to
do
that
kind
of
work,
and
then
we
could
model
at
once
make
figure
out
what
you
know,
what
we
want
to
see
there
and
then
we
could
take
that
work
and
make
a
spec
recommendation
for
it.
H
H
F
H
Way,
just
from
just
from
my
experience
trying
to
generate
you
know,
writing
coaches,
general
fingerprints,
it's
it's
pretty
easy
to
generate
a
fingerprint
for
saying
you
know
the
broader,
a
fingerprint
saying
this
exception
was
thrown
on
this
line,
two
finger
print,
the
individual
instance
of
the
exception.
You
know
across
threads,
it's
more.
A
H
H
A
As
always
with
open,
telemetry,
I
really
think
we
future-proof
ourselves
a
lot
by
ensuring
that
the
context
is
always
accessible
to
any
of
these
operations.
Because
later
you
can
shuffle
some
information
into
that
context.
Like
this
kind
of
fingerprinting
stuff,
it
gives
you
a
little
bit
more
room,
but
to
get
back
to
the
point,
it
sounds
like
there's
some
consensus.
We
we
do
want
to
do
this
work,
but
it's
an
optimization,
and
so
we
want
to
get
the
the
basic
definition
in
first.
A
It
seems
like
maybe
this
version
of
exception
handling
is
fairly
non-preferred
fairly.
A
fair
amount
of
agreement.
Matt
I
would
suggest
opening
a
new
PR
for
this
and
referencing
your
other
PR
just
so
that
people
don't
have
to
read
a
huge
bike
shed.
That's
you
know
about
an
earlier
iteration
I
find
that
it's
usually
helpful.
C
B
A
A
Yeah
yeah
I
think
it's
fine
to
put
examples
in
this
spec
or
linking
to
the
stack
driver,
stuff,
hey
I
found
this
spec
is
actually
in
dire
need
of
more
examples
in
particular
infographics,
but
I
agree
with
the
sentiment
that
there's
a
difference
between
providing
some
examples
versus
like
mandating
like
you
know,
the
spec
says:
thou
shalt.
Do
it
like
this
in
Java
1:6,
you
know.
C
Yeah
I
guess
part
two
was
it
sounds
like
we
should
have
an
API
so
to
spare
the
user
from
having
to
like
format
all
this,
and
since
this
is
really
about
recording
an
exception
like
the
thing
that
I'm
thinking
about
proposing
would
just
be
span
that
record
exception
as
as
an
API
and
you
pass
it
an
exception,
object
and
probably
a
severity.
That's
something
that
it's
gonna
have
to
be
programmer,
provided.
C
A
That
sounds
great
I.
We
haven't
gotten
I,
do
think
in
general.
There's
this
question
of
helper
methods,
you're
proposing
putting
this
on
the
span,
which
seems
fine,
I,
don't
know
if
we're
gonna
end
up
with,
like
some
utility
package.
I
know
that,
generally
speaking,
we
want
to
provide
it's
not
always
possible
because
there's
so
many
different
implementations
of
things
like
HTTP,
but
for
like
the
standard
Lib
stuff
for
anywhere
we
can.
We
want
to
actually
provide
one
of
these
helper
methods
of
like
if
you
want
to
record
semantics
conventions
for
something.
A
C
C
I
I
will
champion
this
I
definitely
feel
comfortable
championing
this
cause.
I
do
still
think
there
are
some
other
voices
and
other
opinions
here
that
aren't
necessarily
like
represented
at
this
meeting
so
yeah,
but
I
can't
speak
for
them.
I.
Think
for
me,
like
this
suits
my
needs
and
it's
a
simple
approach,
and
it's
kind
of
like
it's
a
simple
thing
that
will
get
us.
You
know
an
80
to
90%
of
what
we
need
and
I
think
we
can
work
on
that.
A
H
A
A
That's
the
step
that
we
keep
falling
down
on
so
I
just
want
to
shout
that
out,
since
there
is
some
agreement
here
as
soon
as
this
goes
up,
showing
that
that
agreement
by
hitting
an
approval,
is
really
helpful
to
getting
it
over
the
finish
line.
Even
if
you
are
an
official
approver
for
the
spec
repo.
A
H
H
K
A
K
Generally,
like
what
I'll
do
is
and
I
think
a
lot
of
people
do
this
not
just
me
but
like
when
you
write
instrumentation
you,
you
do
a
try-catch
and
like
surrounding
a
method
and
if
the
instrumentation
throws
I'm
sorry,
if
the
method
that
you're
instrumenting
throws
an
exception
out
of
that
method,
you
catch
it
before
it
leaves
the
method,
and
then
we
throw
it
while
capturing
the
details
in
a
pan.
So
I
mean
you,
you
don't
really
have
context
of
the
severity
like
that
great.
A
K
H
And
then
you
have
the
problem
of
the
individual
programmers.
You
know
writing
code
gone,
you
know
having
different
opinions
on
what
the
severity
is.
You
always
get
junior
ones
that
they.
Oh,
this
is
an
exception.
That's
air
level,
yeah
boys,
air
level.
So
you
still
need,
even
if
you
got
that,
you
still
need
something
on
the
backend
process
to
fix
stuff
like
that
and.
A
Now
that
we're
on
this
subject,
you
know
log
severity,
I
mean
it's
coming
up
here
for
exceptions,
but
this
seems
like
well
one
something
the
logging
working
group
is
thinking
about.
So
as
far
as
like
what
the
log
levels
are
and
whatnot,
we
need
to
collaborate
with
that
group
to
make
sure
when
we
do
eventually
add
full-scale
logging
to
open
telemetry.
We
don't
have
some
funky
version
of
log
severity.
That's
different
than
the
thing
they
want
should.
A
Sort
of
what
I'm
wondering
like
this
log
severity,
this
is
sort
of
not
specific,
to
recording
exceptions
right.
This
is
actually
modifying
the
span
event
API
to
say
like
what's
the
the
log
level
of
this
event,
and
we
could
do
that
with
an
attribute
but
I'm
not
sure
that
it's
an
attribute,
that's
necessarily
attached
to
the
exception
convention.
Right,
like
it's,
maybe
log
severity.
So
it's
own
convention
just
all
of
its
own,
because
you
want
to
say
this
about
every
log
message:
right,
not
just
not
just
exceptional
ones,.
A
Yeah
I
should
say
then
in
open
tracing.
We
called
it
log
and
in
my
head,
I
just
see
these
all
his
logs
get
confused
when
people
make
a
big
deal
about
tracing
being
so
different
from
logging,
but
yeah
yeah
span
events
span.
Events
currently
don't
have
you
know
a
log
level
or
event
level,
but
you'd
want
one
right.
You
want
to
add
a
butt,
debug
events
and
then
turn
them
off
in
production.
Right,
like
that's,
pretty
normal
I.
K
A
F
K
B
A
B
A
A
A
We've
lived
without
severity
so
far
and
I
think
when
we
add
that
in
we
want
to
add
that
in
as
like
a
general
event
or
logging
concept
not
slip
it
in
as
part
of
defining
exceptions,
especially
since
Tyler
is
pointing
out
like
that's
actually
like
it
just
makes
it
more
complicated.
As
someone
writing
instrumentation,
because
you
don't
know
what
to
put
in
that
field,
so.
C
Yeah
I
think
the
thing
that
Tyler
was
talking
about
in
terms
of
having
priority
on
events
is
probably
an
important
thing.
What
possibly
in
orthogonal
cause
in
general,
because
I
know
there's
like
there's
an
event
limit
per
span.
Usually
that's
configured
in
your
SDK
so
like.
If
you
are
over
the
limit,
like
I,
think
it's
kind
of
I
forget
how
it
works.
I
think,
maybe
you
keep
the
last
ones
or
maybe
you
keep
the
first
one.
A
Looking
forward
to
the
PR,
and
maybe
next
week,
we
both
yeah
and
then
for
next
week.
Yeah
there
is
this
issue
of
rate.
You
know,
how
do
you
define
a
span
being
an
error
full
state?
Currently
we
have
status
codes
that
can
do
this.
Is
that
good
enough,
we
just
say,
use
the
status
code,
but
that's
I
think
the
other
issue,
for
maybe
people
if
you
want
to
mull
over
something
between
now
and
next
Thursday.
K
A
But
it's
not
just
exception
right
like
it's.
It's
also
our
403
x'
bad
for
this
endpoint,
but
yes,
certainly
for
exceptions.
It's
like
a
question
of
like.
Are
you
ignoring
this
exception?
Is
this
like
a
super
terrible
exception?
It's
just
a
normal
exception
and
you're
just
handling
it.
The
those
are
the
kind
of
questions
that
come
up
when
we
start
talking
about
what
state
this
fan
is
in
I
mean.
K
A
Right
now,
there's
a
spam
status
code,
so
you
can
say
this
span
itself.
Is
you
know?
Okay
or
it's
in
experience?
An
internal
error?
There's
a
bunch
of
google
status
codes
that
we're
pretty
well
thought
out.
They
don't
cover
everything,
but
there's
also
this
question
yeah
of
like
okay,
you
have
spam
status
codes,
but
then
you
have
things
like
what
does
it
mean
to
have
like
span?
Okay
and
then
black
log
severity
fatal
on
an
event
on
that
span?
Yeah.
H
M
K
F
E
I
E
F
F
A
F
A
H
B
H
A
A
B
M
M
M
M
M
L
M
M
I
I
K
I
K
I
M
I
still
juicing
for
so
Special
Agent
Custer's.
I
I
M
We
we
chat
with
him.
Yes,.
I
B
B
So
recently,
Auto
Java
has
made
a
change
that,
if
context
propagator
fails
to
extract
data
from
the
upstream
like
from
HTTP
request,
then
it
it
does
previously
it
it
updated
the
current
context
with
invalid
file.
Currently
it
doesn't
do
anything,
so
it
just
leaves
context
as
it
was
and
the
problem
with
with
our
tests
that
in
our
test
we
have
that
artificial
extra
trace
wrapped
around
almost
all
of
our
HTTP
server
tests.
B
D
B
M
B
B
B
M
M
M
C
A
M
L
Slightly
like
what
what
changed
was
were
now
no
longer
clearing
it
out
after
we
fail
I'm
saying
that
the
beginning
of
the
propagation,
the
beginning
of
the
extraction
it
should
be
cleared
out
before
anything
happens,
not
after
the
fact
not
after
it
fails
like
let's
change
it
so
that
we
always
clear
it
initially
and
it'd
be
great.
If
the
API
implementation
for
propagators
somehow
did
that
itself,
I,
don't
know
Carlos.
If
you
have
any
thoughts
on
that.
I
I
We
can
do
something
to
add
something
does
something
there.
It
could
be
useful.
Yes,
and
this
is
exactly
the
thing
when
something
was
leaked
and
you
want
to
make
sure
that
the
context
is
actually
like.
You
know
in
a
clean
state,
when
you
request
starts
so
yeah.
We
can
do
that.
Probably
I
need
to
think
about
a
few
ways
to
implement
that
what's
the
correct
way,
but
we
can
definitely
consider.
M
B
B
M
B
I
B
M
I
was
thinking
yeah
doing
that
context,
fruit,
there
or
I
think
gets
us
back
to
our
current
state
and
then
maybe
we'll
open
an
issue,
and
we
can
discuss
about
clearing
the
whole
thread,
local
context,
which
we're
not
doing
currently
anyways,
which
would
require
something
before
we.
You
know
when
at
this
level
that
would
require
sort
of
clearing
and
require
a
whole
nother
layer
in
our
instrumentation
sort
of
to
clear
the
the
whole
context,
I
I.
B
M
J
Can
you
hear
me
yeah,
yeah,
okay,
awesome,
so
I
notice
that
with
auto
instrumentation,
when
your
instrumenting,
like
different
libraries,
that
we
always
create
like
a
new
tracer
within
like
a
decorator?
Is
that,
like
the
pattern
that
we
want
to
use
a
manual
instrumentation,
cuz
I'm,
initially,
my
thought
was
I
would
create
like
one
tracer
and
then
I'd
be
able
to
like
pass
that
into
like
different
objects
and
different,
like
I.
Guess
like
what
clients.
M
So
what
I've
heard
from
folks
when
we
were
having
a
bunch
of
sort
of
discussion
around
spring
and
injection
that,
from
that
perspective,
people
the
spring
community
at
least,
would
prefer
that
are
that
we
not
create
the
tracer
within
our
manual
instrumentation
button
that
they
create
it.
You
get
to
create
it
and
pass
it
in.
We
have
a
way
we
just
have
a
setter
or
a
builder,
or
something
to
pass
that
tracer
in
okay.
J
Okay,
that
makes
sense.
Cuz
I
noticed
that
existing,
like
I,
have
like
a
change
right
now,
where,
like
I,
extract
some
of
that
tracer
code
out
in
Korea,
like
an
abstract
class
I
could
like
link
you
to
it
later.
I
might
do
that
in
other
places
as
well.
If
that's
the
pattern
that
we
want
to
go
with,
I
just
didn't
want
to
like
break
existing
conventions,
so.
J
B
I
believe
what
Morrissey
is
talking
about
this
character,
auto
trade
tracer,
which
inch
has
like
a
name,
not
our
HTTP
server
trade
tracer,
which
has
like
specific
API
but
auto
trader.
Thank
you
have
extract
extract
within
that
simple
request.
What
you're
talking
about
yeah.
J
B
So
so
currently
he
trusts
our
all
our
decorators,
all
our
library
instrumentation.
They
create
like
a
new
tracer.
A
new
tracer
object,
we've
a
name
specific
to
that
implementation,
library
or
instrumented
library.
Both
ways
yeah.
So
the
question
is:
should
that
table
should
be
somehow
share
it
and
what
manual
instrumentation
should
they
create
that
tracer?
Should
they
have
that
from
somewhere
how's
that
share
it
with
our
two
instrumentations
etc?.
M
M
M
M
What
about
defaulting,
having
a
default
but
then
letting
users
in
like
a
builder
or
something
inject
their
own
tracer.
B
So
I
think
that
that's
essentially
what
Munir
did
in
his
pool
full
request
is
that
you
can
give
a
tracer.
You
can
give
auto
tracer
into
our
trace
our
HTTP
server
tracer.
But
if,
if
not
by
default,
you
will
use
that
our
out
instrumentation
has
created
that.
Essentially,
when
your
didn't
hear
or
pull
request.
L
I
guess
I
I
haven't
looked
at
that
PR
and
I.
Don't
feel
like
I
have
enough
context
to
understand
what
like
what
with
the
use
case
or
what
the
use
case
is
trying
to
be
solved
here,
so
manuals
of
rotation,
but
somehow
interacting
with
existing
auto
instrumentation.
That's
why
not
me
yes
doing
direct
manual
written
manual
instrumentation.
You
can
obviously
just
get
your
tracer
from
the
provider
and
use
it
right
and
it
should
just
participate
in
the
trace.
L
M
L
M
L
It
seems
like
that
what
is
written
here,
it
seems
like
a
great
solution
right
if
the,
if
you're
doing
manual
instrumentation-
and
you
want
to
use
the
wrapper
or
whatever
is
it's,
that
being
provided,
give
it
a
tracer
and-
and
you
can
use
in
an
auto
instrumentation-
won't
even
do
the
same
thing
and
you
can
give
it
your
tracer.
The
one
that
you
created
manually,
I,
think
I
think
it
totally
makes
sense
to
me.
J
L
J
So
right
now
I'm
starting
off
like
spring
web.
My
goal
is
like
move
forward
and
use
this
all
over
the
place
for
spring
web
MVC
and
in
create,
like
a
spring
boot
starter,
awesome.
M
L
B
B
J
M
When
your
may
want
to
follow
along
to
honor
AG
issue
here,
okay,
this
is,
he
was
working
he's
working
on
how
we
can
share
the
same
tests
between
auto
instrumentation
and
manual
instrumentation
mmm-hmm.
Since
the
ideas
we
want,
both
of
them
to
capture
the
same
things
under
the
same
conditions,
essentially.
M
Then
you
don't
need
to
worry
about
the
tests
I'm,
adding
tests
there,
because
we'll
pull
over
the
same
tests
once
we
had
all
this
figured
out.
I
think
that
spring
the
rest
template
one
is
not.
We
don't
have
a
corresponding
auto
instrumentation.
Since
we
auto
instrument
the
underlying
HTTP
clients
that
rest
template
uses
so
tests.
There
would
be
helpful,
but
you
might
want
to
wait
again
until
this
is
figured
out.
Yeah.
J
M
M
M
M
So,
let's
see
yeah
I'd
say
that
that
zero
sick
getting
updated
to
zero
six
zero
and
then
I'm
keeping
a
bunch
of
doc
tasks
because
I've
been
using.
This
I
will
using
the
the
release
date
to
push
myself
to
write
tada
some
doc,
so
hopefully
that
will
I'll
get
that
done.
M
J
M
M
Chat
chat,
oh
no,
don't
put
it
on
the
chat,
put
it
here
yeah,
so
you
just
need
to
file
an
issue
basically
in
the
open,
telemetry
community
and
mention
to
sponsors.
M
So
you
know
feel
free
to
mention
myself,
Nikita
John
I'm,
not
sure
if
they're
supposed
to
be
sponsored
like
two
approvers
okay,
so
anybody
who's
an
approver
or
maintainer
which,
on
this
call
we
have
several
Carlos
myself,
Tyler
and
Nikita
John,
so
yeah
feel
free
to
mention
pick
pick
us
and
we
will
approve
you
and
then
you
will
show
up
and
we
can
assign
I
thought.
Didn't
we
assign
something
to
you
once
before
here?