►
From YouTube: 2020-11-11 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
B
Oh
sorry,
I'm
either
I'm
breaking
up
or
you're
breaking
up
but
glad
to
hear
you're.
Here.
That's
awesome.
Welcome.
B
C
C
Topics
what
to
talk
about
well
honorary
I've
been
talking,
and
I
have
been
talking
offline
about
nikita's
bug
about
configuring,
the
sdk
with
an
open,
telemetry,
sorry
with
a
tracer
provider
that
is
not
an
sdk
tracer
provider
causing
all
havoc
to
break
loose.
When
you
try
to
do
any
of
the
management
functions
with
it,.
C
I'm
trying
to
figure
out
what
the
best
solution
or
what
the
right
approach
is
to
solving
this
problem.
We've
been
bouncing
ideas
around
one
of
honorog's
ideas.
If
you,
if
you
configure
the
sdk
with
a
tracer
provider
that
doesn't
implement
the
management
interface
that
you
just
don't
get
a
management
interface,
it
just
does
nothing.
B
So
can
you
can
you
give
just
because
I
think
I
missed
that
issue
yeah.
E
I
want
to
yeah,
I
want
to
provide
a
custom
id
generator.
The
only
way
to
do
that.
Current
right
now
is
to
provide
the
full-blown
tracer
pro
provider,
which
contains
id
generator
so
and-
and
I
do
provide
hdk
tracer
provider,
I
take
a
trace,
ready
provider
builder,
set
id
generator,
build
and
then
sdk
builder
set
tracer
provider
and
it
still
blows
to
my
face.
E
As
such
to
sdk
repo,
but
but
the
question
still
remains,
john
asked
what
if
an
end
user
sets
a
trader
provider
and
then
hit
left
without
the
sdk
management
right
now,.
D
C
You
lo
the
bug
you
logged
was
the
test
case.
You
provided
had
the
tracer
provider
interface
mocked
out.
D
C
Which
I
think,
which
I
I
had
put
in
in
my
fix
as
well
like,
I
think
it
would
actually
fix
this
bug.
Okay,
yeah,
but
my
fix
also
addressed
another.
C
What
I
thought
was
the
bigger,
I
think,
is
actually
a
bigger
issue
and
the
api
we
provide
makes
it
very
easy
for
people
to
do
the
wrong
thing.
If
they
don't
know
what
they're
doing.
C
C
C
In
the
open,
telemetry
sdk
class,
which
implements
the
oma
telemetry
interface
and
in
this
class
somewhere
there's
a
builder,
I
went
too
far
because
most
this
class
is
actually
the
builder
there's
a
builder
which
implements
this
open,
telemetry
builder,
which
is
an
api
interface
all
right
interface
here,
and
this
interface
has
three
methods
on
it:
to
set
a
tracer
provider,
a
meter
provider
in
context,
propagators,
and
so
our
implementation
accepts
a
tracer
provider,
a
meter
provider
and
contacts,
propagators,
oop
context,
propagators,
but
the
the
actual
tracer
provider
that
the
sdk
wants
is
not
a
tracer
provider.
C
D
C
D
C
D
I
mean
that's
a
good
way
to
I
mean
in
that
case
you
would
get
rid
of
all
this
and
whatnot
from
here.
Oh
sorry,
and
just
this
becomes
its
only
job
is
to
make
the
full
open,
telemetry
sdk.
If
you're
going
to
do
a
custom
thing,
you
might
have
to
duplicate
some
logic
we
have
in
here.
It's
probably
not
a
lot
and
just
use
the
normal
api
builder
yeah.
C
C
Yeah
because
default
open
telemetry.
If
I
remember.
C
C
C
C
Same
resources
yeah,
so
maybe
the
answer
to
that
is.
We
probably
need
a
resource
spi
that
you
can
just
wire
together
and
have
it
all
be
done.
Probably
I'm
not
sure.
C
So
anyway,
in
my
my
bug
fix
pr,
I
did
comment
that
I
thought
there
was
only
one
way
to
solve
the
problem
and
I
think
talking
it
through.
There's
probably
the
better
way
is
to
just
rip
the
band-aid
off
and
get
rid
of
or
clean
up
the
open,
telemetry
sdk
instance.
So
it
doesn't
pretend
to
be
like
being
able
to
add
things
that
aren't
part
of
it
like
it's
normal
sdk
implementation
so,
like
I
can
take
that
on
probably
tomorrow.
I
think
so.
C
D
C
D
So
I
was
hoping
we'd
remove.
Most
of
the
globals
like,
for
example,
set
propagators
like
do.
We
think
we
need
set
propagators.
C
D
D
C
D
B
So
in
library
instrumentation
like
grpc,
for
example,
we
fall
back
to
the
global
right.
If,
if
it's
not
configured,
if
they
don't
pass,
I
mean.
B
D
C
C
B
Even
the
get
global
propagators
is
that,
why
isn't
that
get
and
then
get
propagators.
D
E
C
C
Was
gonna
say
if
people
haven't
looked
at
nikita's
issue
with
the
the
craziness
that
every
little
piece
of
the
sdk
you
can
figure
in
a
different
way.
D
D
E
C
D
C
Implementation
right
now,
which
was
the
next
thing
I
wanted
to
talk
about
thanks
for
setting
me
up
nicely
there.
B
Before
you
leave
that
screen,
so
the
get
pro
get
global
propagators
method
itself.
Honorable,
is
that
what
you
were
mentioning
that
in
the
pr
that
people
didn't
want
to
get
rid
of
that
method?.
D
Carlos
in
particular,
okay
yeah,
you
suggested
a
gut
thing
which
seemed
short
enough,
but
but
but
I
at
the
time,
I
don't
think
we
had
realized
that
we
wouldn't
need
this.
We
would
need
this
global
word
inside
it,
like
even
I
didn't
realize
that
we
couldn't
use
the
same
name
until
I
tried
it
right
now
that
the
name
has
become
this
long,
maybe
yeah.
You
can't
do
this
right
because
yeah
yeah,
so
I
don't
know
if,
after
we
reconsidered
that
decision
after
this
naming
happened,.
C
B
C
From
scratch,
well
less
from
scratch
from
josh's
sdk
specification.
Oh.
B
C
I
didn't
originally
intend
it
to
be
a
way
to
vet
his
specification,
but
it's
turning
into
that
because
I'm
finding
things
that
I'm
like
well,
I
don't
know
how
to
implement
this.
The
spec
doesn't
tell
me
what
I'm
supposed
to
do
in
this
particular,
but
the
actual
implementation
is
in
at
least,
I
think
much
simpler.
B
C
D
C
A
it
gives
a
better
handle,
I
think,
on
how
to
implement
something
that
could
support
both
push
and
pull
in
the
same
sdk.
Although
that
part
of
is
inspect,
and
that
was
actually
like.
I
started
to.
D
C
And
look
for
that,
I'm,
like
I,
don't
know
how
to
make
this
work,
but
the
basic
idea,
it's
actually
really
really
simple.
Is
we
have
a
thing
called
a
controller
that
has
access
to
an
accumulator,
a
processor
and
an
exporter
and
the
cycle
that
is
either
timed
or
done
this?
C
This
would
be
a
method
that
could
be
called
by
a
poll
or
by
a
pole-based
export
also,
but
you
basically,
the
accumulator
is
what
actually
is
implementing
essentially
implementing
the
api,
and
so
the
controller
just
goes
and
tells
the
processor
that
things
are
starting
tells
the
accumulator
to
send
all
its
data
to
the
processor
then
gets
all
the
processors,
all
the
metric
data
out
of
the
processor
and
then
send
just
the
exporter
and
then
goes
back
to
sleep,
and
it's
done,
and
the
job
of
the
accumulator,
as
I
said,
is
essentially
to
implement
the
the
api
via
a
bunch
of
methods
that
basically
just
the
instrument
objects
just
delegate
directly
over
the
accumulator
and
don't
do
anything
else.
C
So
the
processor's
job
is
to
take
the
data
from
well
to
receive
the
data
from
the
accumulator
and
then
turn
it
into
exportable
data.
C
C
Yes,
okay,
so
you
could
implement
your
own
processor
that
could
do
label
reduction
or
label
like
add
additional
labels,
or
also
any
of
that
sort
of
thing.
C
Okay,
so
one
thing
that's
interesting
is
this:
the
processor
is
where
all
of
the
long-lived
state
is.
So
if
you
have
cumulative
metrics
that
are
accumulating
beyond
a
single
cycle
like
counters
that
need
to
sum
forever,
the
processor
holds
all
that
state
and
the
accumulator
is
super.
Essentially
its
only
state
lasts
for
one
collection
cycle,
and
then
it
drops
everything
and
starts
over
again,
so
the
accumulator
can
be
kind
of
a
one
thing
that
works
the
same
always
and
then
the
processor
can
be
where
the
the
smarts
are
built
around.
So.
B
The
views
stuff-
that's
in
processors,
it's.
C
D
C
Going
to
be
essentially
reusable
with
a
couple
little
tweaks,
and
I
mean
it's
going
to
be
a
long
time
before,
unless
somebody
like
we,
we
basically
pile
on
and
all
kind
of
try
to
crank
out
all
the
millions
of
to
do's.
In
here
it's
gonna
be
a
while
before
this
is
kind
of
production
ready,
I
mean
you
can
see
like
if
you
go
to
the
accumulator.
It's
like
to
do.
C
Students
to
do
studios
to
do
is,
if
you
go
into
anywhere
well,
maybe
not
an
interface
but
there's
basically
just
to-do's
throughout
the
entire
code
base.
The
controller
has
to
do
add,
a
dependency
on
micrometer
and
solve
those
out
yeah.
This
is
well.
This
is
another
experiment
that
I
really
was
interested
in,
doing
which
was
running
the
same
thing
purely
with
micrometer
as
a
completely
you
know
what
it
looks
like,
but
then
that
wouldn't
obviously
obviously
that
wouldn't
match
the
spec
either.
C
But
this
has
been
a
good
exercise,
an
excellent
exercise
for
me
at
least
to
really
understand
what
it
takes
to
to
implement
one
of
these
but
yeah.
I
don't
know
exactly
what
we
should
do,
whether
we
should
try
to
morph
the
existing
implementation
into
something
that
looks
like
this
or
whether
we
should
start
from
scratch
and
try
to
build
it,
because
really,
the
existing
implementation
looks
nothing
like
this
at
all.
C
D
D
D
C
Josh
josh
and
bogdan,
and
I
were
kind
of
like
well-
you
can
kind
of
squint
real
hard
and
see
pieces
of
the
spec
in
there.
So
maybe
it's
okay,
but
it's
also
it's
just
it's
really
hard
to
understand
our
current.
I
don't
know
if
you've
spent
any
time
looking
at
our
metrics
sdk,
but.
D
D
D
C
Not
exactly
the
same
but
yeah
so
anyway,
that's
what
I've
been
spending.
My
spare
time
working
on
is
trying
to
at
least
get
a
something
that
I
can
demonstrate
as
an
alternative
to
our
current
sdk,
for
something
really
simple,
the
bummer
that
I
have
right
now
is
I
really
want
to
take
our
existing
exporters
and
plug
them
into
it,
but
those
exporter
interface
live
in
the
other
sdk
implementation.
C
So
I
can't,
unless
I
depend
on
the
other
sdk
implementation,
which
is
would
be
very
strange,
especially
for.
C
If
I
can
meet,
this
is
good,
I
could
change,
I
mean,
hopefully
I
think
the
idea
would
be.
Maybe
I
could
change
the
dependency
like,
for
example,
if
I
took
the
where's
an
exporter
if
I
took
prometheus,
that's
a
bad
example
for
right
now,
but
if
I
took
the
build
gradle
here
and
change
this
to
depend
on.
C
C
C
Oh,
that
could
be,
but
the
only
so
the
only
metrics
exporter
we
have
is
prometheus
and
I
bet
yeah.
It
depends
on
the
sdk
just
out
of
laziness.
Yeah,
that's
that's
my
guess
at
least
copy
paste
anyway,
so
I
could
potentially
change
the
otlp
exporter
to
depend
on
slightly
different
dependencies
and
see
if
it
all
works
anyway.
C
If
anyone
is
really
interested
in
metrics,
I
would
love
assistance
on
getting
this
working
and
cranking
through
cranking
through
all
the
hundreds
of
to
do's,
maybe
not
hundreds,
dozens
of
twos
that
I
have
been
littering
littering
the
code
with
yeah.
I.
B
Was
gonna
say
I
don't
think
that
any
of
us
will
object
to
the
rewriting
the
sdk,
the
metrics
sdk,
pushing
out
the
ga
time
frame,
because
it
gives
us
more
time
for
ga
stuff.
C
Oh
yeah,
I'm
still
not
sure,
that's
true
in
the
spec
meeting
this
morning.
C
Ted
actually
has
the
complete
opposite
impression
that
we're
gonna
ga
tracing
separately
from
metrics,
and
so
I
like
had
to
call
a
stop
to
things
in
the
middle
meeting.
I'm
like
hey.
Can
you
just
go
talk
to
your
friends
on
the
governance
committee
and
the
technical
committee
and
get
everyone
to
agree
on
what
we're
actually
doing.
B
Yeah,
that
would
be
good,
because
that
is
completely
not
what
the
messaging
has
been
in.
C
It's
my
guess,
so
I
guess
one
question
I
have
while
and
then
I'll
go
to.
Bed
is,
if
I
put
in
a
pr
that
had
all
these
to
do's
in
it
and
just
had
kind
of
end
to
end
implementation
of
one
single
counter
with
a
bunch
of
stuff
hard-coded.
C
D
C
C
Yeah
a
rewrite
I
mean,
I
think
I
think
he
doesn't
care
about
the
sdk
spec
honestly.
D
C
C
Brought
this
up
repeatedly
over
the
last
nine
months
in
the
metrics,
yeah
and
apparently
josh
said
that
carlos
is
starting
to
look
at
the
metrics
sdk.
C
You
know
he
hasn't
talked
to
me
about
it
at
all,
but
I
think
to
try
to
figure
out
how
to
reconcile
so
I'm
going
to
reach
out
to
carlos
I'll
talk
to
him
tomorrow
at
the
just
at
the
regular
sig
meeting
and
I'll
talk
about
kind
of
what
I've
been
up
to
and
what
my
plan.
What
like
I,
I
created
an
issue
in
the
repo
like
a
week
ago
saying
we
need
to
rewrite
the
sdk,
no
response
at
all.
D
D
C
I'll
I'm
gonna
put
that
front
and
center
in
the
agenda
for
tomorrow
morning
to
hopefully
get
some
agreement
that
we
either
are
not
going
to
do
it
or
we're
I
mean
if
we
aren't
going
to
do
it.
I'd
like
to
have
some
delete
input
from
other
people
about
what
we
should
be
doing.
D
B
Yeah,
I'm
sorry,
we
don't
have
too
much.
I
don't
have
too
much
in
thoughts
about
metrics.
Yet
since.
C
Nikita
are
any
of
the
plumber
folks
like
interested
in
metrics.
Like
is
this
something
that
someone
from
your
side
of
the
world
would
be
interested
in
collaborating
on.
E
B
C
It's
pretty
it's
pretty
fun,
there's
actually
some
really
interesting
problems
to
solve
in
there
definitely
different
problems
than
tracing
so
yeah
anyway.
B
D
D
C
Sampler
yeah
there's
a
few
yeah
that
one
there's
a
few
of
the
these
newer,
newer
ones
that
the
sdk
doesn't
have
in
it.
I
haven't
get
hotel
propagators.
C
An
sdk
yeah,
there's
there's
some
relatively
recent
ones
that
have
come
in
that
we've
not
implemented
in
in
the
sdk
itself.
I
think
I'm
totally
on
board
with
it
the
the
whatever
the
compliance
matrix.
I
didn't
fill
them
in,
so
they
it's
not
marked
as
being
implemented
by
the
sdk.
D
D
B
So
for
hotel
exporter
to
be
in
the
sdk,
would
it
still
you
would
still
have
to
find
it?
The
the
user
would
still
have
to
add
the
exporter
to
their
class
path
and
then
they
could
use
that
to
specify,
and
then
you
would,
if
you
find.
D
B
We
do
it
compile
time
we
do
at
compile
time
for
those
just
to
save
us.
The
cost
of
runtime
shading.
B
Could
well,
we
can
still
shade
them
in
the
when
we
build
the
java
agent
all
together
and
that
would
have
the
advantage
of
those
exporters.
B
The
standalone,
sdk
exporters
would
work
with
the
the
hotel
exporter
jar.
D
B
B
E
Mean
I
I'm
thinking
about,
so
I
am,
if
I'm
using
case
decay
manually,
I
want
to
like
instrument
my
application
using
api
and
mdk
manually.
E
I
have
to
configure
everything
and
like
put
everything
together
in
my
code
base,
and
I
still
will
have
to
do
some
coding
configuration
will.
I
I
mean
if,
if
I
still
have
to
write
some
code
to
put
things
together,
then
in
addition
to
that,
you
think
environment
variable
doesn't
give
me
anything.
That's
true.
E
B
B
Possibly
might
want
to
do
that
post
deployment,
the
I
I
would
love
for
this
to
go
this
one
to
go
into
the
sdk
only
because
it's
really
complicated
and
propagator.
Where
is
baggage?
B
Yes,
we've
been
having
this
carlos
has
been
helping
us,
but
if
you
look
at
this
pr,
the
the
rules
for
oh
there's,
so
many
it
gave
me
a
load
more.
The
rules
for
adding
the
propagators
just
to
map
this
very
simple
hotel
propagators
to
the
code
is
quite
complicated
and.
D
E
My
point
is,
I
think,
both
instrumentation
repo
and
sdk
repo
currently
has
much
more
pressing
issues
than
changing
that
unless
we
have
a
good
rhythm
for
that.
D
E
B
B
This
one
I
plan
to
because
we're
going
to
our
next
release
is
going
to
be
end
of
next
week,
possibly
if
we're
going
to
the
two-week
releases.
So
my
goal
is
to
get
this
into
that
release.
B
But
the
other
two
yeah,
I
guess
just
need
some,
the
the
other
two
aren't
that
hard.
I
I
can
try
to
cherry
pick,
those
off.
B
B
Discussion
of
auto
instrumentation-
and
that
was
one
of
the
things
that
was
high
on
people's
mind-
was
not
having
those
reduced
duplicate
instrumentation,
but.
D
B
E
C
B
B
Okay,
yeah,
especially
if
we
don't
think
there's
anything,
I
guess
the
if
we
don't
think
there's
anything
that
would
be
that
we
need
that
would
prevent
like
that.
We
would
need
a
backward
incompatible
change
later
in
order
to
support.
B
B
I
don't
know
we
can
definitely
bump
it
off
of
a
p1.
D
B
B
D
B
D
B
Yeah,
but
I
I
agree
that
it's
it
definitely.
B
D
B
Yeah
all
right
yeah.
I
think
this
is
actually
more
probably
more
on
me
anyway,
if
I
care
about
it,
because
the
idea
was
kind
of
sort
of
the
idea
behind
this
is
the
idea
of
infrastructure
attached
like
within,
say,
azure
app
services,
auto
attaching
the
java
agent
and
not
causing
problems.
D
B
Considerate
of
this
kind
of
thing,
but
I
I
can
live
with
it,
not
being
a
p1.
D
B
Haven't
looked
at
that
when
I
looked
at
some
early
drafts
seemed
very
targeted
at
sort
of
the
sdk
benchmarking.
E
E
E
The
problem
that
I
that
I'm
currently
worrying
about
is
that,
in
with
this
time,
our
ripple
will
grow
large
and
larger
as
more
instrumentations
will
be
added,
and
I
don't
think
that's
sustainable
so
longer
build
times
more
fragile,
more
prone
to
issues
new
versions
released.
We
we
are
broke
and
if
that
specific
instrumentation
wasn't
wasn't
written
by
us
in
the
first
place,
what
should
we
do
if
somebody
instruments
some
obscure
library
and
the
new
version
of
that
library
breaks
instrumentations?
E
We
we
end
with
broken
revolution.
B
That
was
a
bunch
of
things
on.
Did
I
capture
longer
build
times
new
versions,
more
or
less
yeah?
Okay,.
E
E
D
E
Still
we
we
still
certainly
have
to
have
like
the
most
popular
instrumentation
like
the
list
we
have
in
p1
or
roadmap,
so
some
instrumentations
probably
should
be
in
our
app
and
maintained
by
us
but,
for
example,
the
sprint
instrumentations,
which
may
be
supported
by
spring
people
not
by
us,
although
spring
is
tier
one
I
don't
know
and
well
and
but
some
other
more
obscure,
like
I
don't
know,
khtp
like
five
people
in
the
world,
use
that
and
we
still
you
have
that.
B
This
sounds
good
to
me,
I
mean
I
I
mean
from
my
particular
interest-
is
primarily
the
tier
one
instrumentation.
It
helps.
D
E
E
I
don't
know
so
I
I
I
mean.
I
think
what
what
I
am
trying
to
achieve
is
to
have
some
processing
place
which
allow
us
to.
E
E
So
that
first
objective,
even
even
when
we
have
country
people,
that
means
we
have
to
like
somehow
I
don't
know-
exclude
broken
library
from
release
prevent
release.
If
some
broken
library
don't
release
the
all
in
all
repo
at
all-
or
I
don't
know,
should
we
have
some
start
dot
open,
telemetry
dot,
io
like
sprint
boot
has
and
like,
like
everybody
can
compile
around
the
distro.
I
don't
know.
B
E
D
D
D
E
B
It
feels
like
I
know,
maybe
going
in
the
once
worse,
you
know
more
stable,
maybe
it's
not
as
much
of
a
benefit,
but
right
now
like
I
was
thinking
of
all
the
work
that
mateos
has
been
doing.
Refactoring
work
that
some
of
that
refactoring
work
would
be,
I
think,
easier
across
a
smaller
set
of
instrumentation
in
the
main
repo
and
then
once
we
release
then
update
the
contrib,
but
then
also
that
has
downsides
also
of
things
getting
out
of
sync.
So.
B
Yeah,
I
wonder
what
we
can
do
about
that
because,
like
I
always
troubleshooting,
the
muzzle
breakage
like
a
week
like
recently-
and
I
was
trying
to
it-
was
where
I
was
trying
to
bisect-
commits
to
see
where.
D
B
D
E
E
D
D
B
E
D
E
A
B
You
know
they
have
a.
They
had
a
oh,
it's
not
showing
up.
They
had
a
cool
glow
root
distribution,
yeah,
a
bullfrog
artifactory
specific
java
apm,
based
on
glow
rate.
D
E
It
certainly
requires
a
lot
of
thought
about.
How
do
we
build
them,
how
to
package
them
so
the
whole
infrastructure
part?
So
we
certainly
will
not
do
anything
right
now,
but.
E
B
It's
a
good
point,
I
mean
it's,
not
our
sort
of
our
goal
for
the
distros
is
like
nikita's
demo,
which
nikita
in
your
distro
demo,
I'm
assuming
you're
pulling
in
the
whole
agent.
Yes,.
B
D
Like
we
published
a
thousand
artifacts,
I
was
actually
really
surprised
by
the
number,
but
then
I
realized
we
were
like.
I
didn't
think
we
were
publishing
these
until
I
looked
and
I
was
like:
oh
we're
actually
publishing
all
these
java
agent
components.
It
doesn't
seem
like
we
need
to
cut
that
number
down
a
lot.
D
B
D
B
Yeah,
that's
fine,
actually,
I'm
technically
not
pulling
them
from
the
the,
because
I
have
a
fork
and
build
it
locally
anyway.
A
B
E
B
D
E
D
D
E
Well,
not
for
me,
but
it's
still
one
reason
to
like
it.
It's
actually
very
pity
that
we
are
in
that
damn
lockdown
and
I
cannot
get
face
to
face
with
jfrog
people
on
some
conference
like
to
sit
down
and
have
a
really
hard
honest
talk.
What
the
hell
is
going
on,
because
the
the
bintry
bin
tray,
gradle,
plugin
last
release
was
in
like
in
spring
and
then
almost
total
silence.
E
D
A
reason
yeah,
it's
too
bad,
the
vintage
doesn't
support
normal
maven
publishing.
That
seems
like
it
could
be
more
stable
but
anyways
so
context
core
routines.
So
I
was
extremely
distracted
yesterday
by
this
issue
that
happened
like
it
was
basically
a
security
issue
and
thinking
about,
I
think
it
does
apply
to
us.
In
some
sense
I
thought
it'd
be
good.
If
I
go
through
it,
if
you
stop
sometime.
A
D
D
They
did
the
same
way
to
propagate
the
context,
which
was
setting
the
segment
into
the
thread
local
same
as
our
span.maker
and
after
thinking
about
this
a
long
time.
I
think
that's
just
completely
broken
code.
In
any
situation
like
you
can't
modify
a
thread
local
in
a
kotlin
coroutine
reliably,
because
your
function
once
it
suspends
something
else,
will
get
resumed
at
who
knows
where,
in
this
flow,
whether
it's
it's
probably
after
it
already
mounted
it's
red
locus.
It's
not
going
to
remount
it
and.
E
D
E
D
And
we
have
some
issues,
I'm
still
not
sure
if
it
works
or
not,
but
so
just
the
one
observation
I
had,
though,
is
that,
since
this
is
kotlin
code
anyways
like
users
just
shouldn't
be
calling
make
current,
I
think
they
should
use
a
kotlin
idiom
instead
was
sort
of
the
feeling
I
got
if
you,
okay,
so
in
the
maybe
my
pr
that
I
just
sent
can
explain
it
a
little
bit.
Let's.
A
B
So
is
jfrog
a
are
they
in
estonia.
B
B
Yeah,
looking
for
not
not
looking
forward
to
having
open
telemetry
users,
giving
us
that
same
grief,.
D
So
I
just
think
this
pierce,
I
don't
think
I've
got
a
chance
to
look
at
it,
but
after
just
thinking
about
kotlin
all
day
yesterday,
so
if
someone's
not
using
the
agent.
So
first
I
want
to
like
the
example
I
was
describing
was
someone
who's
not
using
the
agent
and
what
happens
in
that
situation
then.
Is
that
the
threat
the
wrong
segment
gets?
The
wrong
span
gets
attached
to
another
spin
and.
D
That's
yeah,
I
don't
know
what
techniques
exist
for
that,
but
we
don't
yeah
yeah
and
so
that's
what
happened
and
that,
like
I
got
paged
at
4
30
to
explain
kotlin
to
people
like
what's
going
on,
but
anyways.
What
I
noticed
here
and
the
code
that
basically.
D
Instead,
we
have
span.mic
current
here,
and
so
I'm
wondering
if
just
banned.micron
is
even
valid
code
to
have
here
like
is
that
something
that
is
even
something
we're
supposed
to
support,
because
it's
not,
for
example,
if
the
agent
wasn't
there,
then
it'd
be
just
a
disaster
as
I
described,
and
I
don't
think
it's
the
agent's
job
to
solve
security
issues
like
that.
So
that's
sort
of
the
idea
that
came
to
mind.
A
B
You
could
in
suspend
oh,
I
didn't
yeah.
I
don't
understand.
D
B
D
This
so
yeah,
so
this
delay
is
basically
then
going
to
cause
this
core
routine,
to
suspend
and
another
core
routine
to
get
resumed
on
the
same
thread.
But
if
this
was
make.
C
E
D
Is
adding
the
span
to
that
red
local?
As
I
said
by
using
this
mechanism,
it
makes
sure
kotlin
does
it
rather
than
the
user,
and
so
here,
if
it's
http,
client
or
whatever,
that
would
still
be
able
to
read
the
span
from
the
thread:
local,
that's
fine,
and
so
it's
more
about
if
we
use
the
make
current
method
itself,
because
that's
a
java
mechanism,
not
a
kotlin
mechanism,
we'll
set
the
thread
local,
we
won't
clear
it
when
suspending,
and
that
is
that
leads
to
crosstalk.
D
Okay,
and
so
it's
just-
you
define
it's
like
our
conflict
storage.
Basically,
it
has
a
method.
This
is
essentially
on
resume.
What
you
do
when
you
resume
so
then
you
call
me
current
and
then
restore
threat
context
and
when
it's
suspended,
then
you
close
the
scope,
and
so,
if
you
define
this
and
pass
this.
B
B
D
E
Okay,
now
I
see
what
you're
doing
here.
So
what
what
you
are
doing?
You
yeah.
I
now
read
the
title
pull
request
and
I
will
process
that,
okay.
So
what
what?
What
you're
saying
is
that
if
you
use
custom
code
routines-
and
you
want
to
have
the
manual
that
span
management
or
context
management,
you
shouldn't
use
the
usual
span.car
and
my
current
whatnot
you
should.
D
B
D
D
E
B
D
B
Yeah,
I
did
not
know
the
the
that
yeah,
that
literally
in
inline,
in
a
method.
E
B
D
B
Yeah,
so
the
x-ray
sdk
is
kotlin,
it
uses
kotlin.
B
So
much
submit
so
much
to
problems
and
new
things
to
dealing
with
the
brave
new
async
world.
D
D
D
D
Yeah
I
mean
yeah
loom,
should
have
a
lot
of
these
things
built
in,
but
yeah
right
let's.net
is
interesting.
If
you
ever
look
at
net
like
open
telemetry
implements
very
little
we're
just
using
all
the
mechanisms
that
dotnet
has
already
integrated
for
tracing
and
so
yeah.
E
E
D
B
Yeah
so
I'll
bring
up
on
nikita,
we'll,
let's
bring
up
the
the
contrib
split
idea
on
thursday,
get
people's
feedback
on
that
and
show
them
the
list
of
the
tier
one
tier
two
sort
of
instrumentations,
because
I
I
don't
know
if
that
would
be
contentious
where
we
draw
that.
E
B
E
D
B
Get
to
triaging
this
week
so
next
week
you.
C
E
E
E
B
B
B
Bogdan
was
so
anurag
was
trying
to
convert
some
api
classes
into
interfaces
so
that
like
span
context,
so
that
we
could
back
them
by
the
same
in
our
bridge
by
the
same
implementation.
E
Okay,
now
I
understand
so
asked,
but
then,
if
he
wants
to
talk
about
the
wish
of
us
to
come
to
our
meeting.