►
From YouTube: 2020-10-07 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
C
Okay,
so
I'm
not
sure
who
added
this
first
item,
but
this
is
the
diagnostic
channel
proposal
in
node.
I
was
this
valentine.
Was
this
you.
A
I
think
maybe
I
added
it
last
week,
sometime
yeah
through,
like
various
channels,
I
think
the
person
who
opened
this
was
just
trying
to
get
like
feedback
from
people
who
are
interested
in
such
things.
A
Yeah,
it's
like
this
is
a
thing
that
you
know
he's
been
working
hard
on
to
build
into
build
into
node,
and
I
think
his
his
goal
is
that,
like
you
know,
apms,
and
just
generally,
people
in
observability
would
be
able
to
make
use
of
this.
So.
C
A
Yeah,
I
think
you
know
for
us
in
the
short
term
like
something
like
this
is
probably
not
super
helpful.
Just
because,
like
we
support
both
browser
and
node.
So
in
order
to
really
take
advantage
of
this,
it
would
probably
have
to
be
in
both
places.
But
but
who
knows
if
this
successfully
goes
into
one
javascript
engine,
it
might
show
up?
In
others,.
D
You
might
be
able
to
yeah,
I
I
wasn't.
I
was
monitoring
this
these
issues
I
already
commented,
I
mean
just
to
have
some
benchmark
and
yeah,
it's
already
more
performant
than
the
patching
method.
So
it's
always
interesting.
A
D
To
use
new
technologies
like
this,
however,
they
are
still
iterating
on
the
cons
or
on
show
concept,
because
they,
they
will
add
the
concept
of
spam,
which
we,
which
we
have
on
interesting
side.
But
it's
still
like
do
they
really
want
to
have
the
same
concept
as
the
tracing
over
the
over
the
the
monitoring
in
the
general,
because
this
this
specific
pair
was
more
like
to
be
able
to
debug
everything
that's
going
on
on
every
every
libraries,
so
I
think
we
should
still
look
into
where
they
are
going
but
yeah
on
on
the.
D
I
think
it's
still
too
early
to
to
just
judge
what,
how
cool
we
can
interview
it.
D
I
was
just
saying
that
they
are:
they
are
still
iterating
on
the
on
the
concept
on
the
bus
contest.
So
oh
yeah,
sorry,
I
refinished
first
so
yeah.
It's
still
it's
writing
on
the
player,
so
we
still
need
just
need
to
work
on
it
to
be
stable.
I
think,
and
when
it
will
be
done,
I
will
look
into
it
and
how
we
can
integrate.
I
think
because
it.
A
C
C
B
Start,
yes,
I
mean
the
country
is
clean,
so
it's
waiting
for
the
main
reaper,
but
I
was
hoping
too
much
the
back
with
the
context
propagation,
but
it's
still
not
so
after
this
I
was
hoping
to
prepare.
You
know
a
new
version,
but.
C
Okay,
so
there
are
two
potential
fixes
for
this:
let's
see
if
this
is
one
of
them-
and
this
is
one
of
them
right.
C
I
guess
I
I
must
just
not
understand
this
issue
well
enough,
because
we've
had
some
ongoing
discussion
here,
but
I
don't.
I
don't
see
what
bug
this
would.
B
So
basically,
if
we
don't
do
this,
then
we,
for
example,
open
tracing.
You
will
have
two
groups
of
the
spans
instead
of
one,
so
they
won't
be
connected
to
each
other
and
exactly
the
same
problem
is
mentioned
by
those
guys
that
they
also
don't
have.
They
don't
have
this
connection
between
the
context.
B
Not
really
not
really,
because
I
mean
you
only
have
this
information
in
the
http,
so
this
is
already
done
the
same
way
for
incoming
request
and
when
you
try
to
send
something
out,
you
are
injecting
the
context
propagation
like,
for
example,
b3
header
and
all
it
does,
and
then
we
create
a
new
span
like,
for
example,
that
this
this
particular
request
is
outgoing
here
and
because
like
like,
for
example,
this
pink
here
and
because
it
doesn't
have
the
context
propagation
from
all
those
you
know
from
the
previous
one.
It
creates
a
new
context.
B
So
all
I
do
is
basically
creating
a
surrounding
creation
of
the
new
span
within
the
context
from
the
b3
header.
A
In
this
example,
I
think
there's
seems
to
be
a
couple
things.
One
thing
I
want
to
clarify,
and
one
thing
I
want
to
mention,
so
I
think
one
one
thing
that
makes
this
hard
is
that
open
tracing
js
doesn't
really
have
like
a
start
active
span
or
like
make
this
thing
active,
and
I
think
that
might
play
into
this
to
some
degree.
A
That
was
my
statement.
I
think
my
question
is
in
this
particular
scenario
is:
is
the
thing
that's
happening?
Is
there?
Is
there
open
tracing
instrumentation
for
this
http
request
and
then
hotel
instrumentation
for
this
http
request
and
are
both
of
them
basically
injecting
into
the
same
headers
like
one
after
another,
and
is
that
what
you're
extracting
is
like
the
the
inject
from.
B
Like
imagine
you
don't
have
the
the
b3
header
yeah,
then
the
the
new
span
should
be
created
in
the
context
of
whatever
is
on
the
higher
and
the
pr
that
and
the
whole
discussion
that
was
fixed
by
the
valentine
is
also
on
this
one
because
they
have
the
context
to
be
propagated.
So
that
means
this
can
be
extracted
from
the
header,
because
this
is
what
is
coming
here,
so
you
are
expecting
that
all
the
spans
that
were
creating
when
doing
some
certain
requests
should
should
be
bounded
together
with
the
context
here.
B
B
It
wasn't
ejected
at
all
so
when
the
new
span
is
being
created
for
outgoing
the
request
it
checked
for
the
context,
the
context
doesn't
exist,
so
it
creates
a
new
one.
So
if
you
go
to
the
fixes,
then.
B
B
D
Just
I
think,
that's
the
main
problem.
If
you
look
at
the
tests
that
you
added
you
just
inject
them
inside
the
http
requests,
and
that's
that's
not
what
how
the
production
is
supposed
to
work.
You're
not
supposed
to
inject
the
the
headers
there
you're
it's
supposed
to
be
automatic
by
the
propagators
and
by
the
instrumentations.
C
B
More
likely
to
come
down
the
road
too
well
here,
you're,
basically
requesting
something-
and
you
add
the
headers
right,
you're,
adding
the
headers,
which
you,
which
basically
means
anything
that
will
be
created.
The
spans
that
will
be
created
for
this
particular
request
should
have
a
context
of
that
headers.
D
Yeah
but
but
you
are
setting
them
when
you
are
doing
the
request,
and
it's
not
the
it's
not
a,
I
mean
it's
not
the
use
case
that
the
default
use
case
that
you
should
use
the
propagation
should
be
done
automatically.
So
I
don't
I
mean
currently,
you
are
right
that
it's
not
possible
to
do
this,
but
what
is
the
use
case?
B
B
B
I
don't
really
need
to
inject
anything.
All
I
want
to
do
is
imagine
I'm
doing
some
requests,
and
this
can
be
done
by
any
third
line.
Anything
and
all
it
does.
It
just
has
the
headers,
but
where
did
these
headers
come
from
setting
up
them
like
now,
because
let's
say
I
want,
I
want
to
make
a
request
that
will
be
so
to
see
normally
those
headers
will
be
propagated
and
they
are
called
like
x-dummy,
because
I
mean
that's
how
the
test
was
written.
So
this
exam
is
in
fact
mapped
into
this.
B
D
B
Well,
you
can
basically
for
any
incoming
request
you
can
get.
You
can
extract
them
from
the
incoming
clickers,
but
this
is
just
a
test.
So
why
should
I
inject
anything
here
if
I
just
can
simply
add
some
headers
right?
Yes,.
D
B
Yeah,
but
if
the
request
is
coming
from
the
server,
let's
say
from
one
server
to
another
yeah,
you
are
sending
crickets
from
one
server
to
another.
So
imagine
those
mock
is
one
survey,
something
is
there
and
there
can
be
completely
different
instrumentation
and
all
it
does.
In
fact,
in
forget
about
an
effort
library
all
it
does
all
this
v3
propagation
is
simply
setting
up
the
correct
headers
and
now
it's
coming
to
our
backend
and
our
backend
should
extract
those
headers
when
they
create
this
new
span
and
whatever
is
happening
there.
B
Those
funds
should
be
created
in
the
context
of
this
propagation
overview.
Sorry,
they
should
be
created
in
the
in
the
context
of
the
threaders.
D
Yeah,
okay,
but
the
the.
If
you
want
to
do
this,
you
should
use
the
same
the
same
code
that
you
implemented
inside
the
http
you
should.
You
should
use
it
outside
of
the
http
plugin
and
then
extract
yourself,
the
header
from
the
http
and
then
set
them
inside
the
context.
I
don't
think
it
should
be
the
the
limitation
that
does
this.
B
B
C
D
Why,
well,
I
mean
I
mean,
if
you
want
to,
you,
should
use
the
you
should
set
them
inside
the
context,
and
so
it
will
be
done
automatically
by
http.
It
will
be
sent
automatically
by
the
http
instrumentation
right.
So
instead.
D
B
You
are
using
already
open
telemetry
for
that,
and
this
is
not
the
case.
The
cases
you
are
having
a
pure
request
with
some
headers
and
that's
it
nothing
more
and
then
you're,
adding
open
telemetry
to
instrument
everything
automatically,
and
you
don't
want
to
modify
your
code
in
each
place
to
inject
something.
C
B
Forget
now
about
open
tracing,
it
can
be
any
other
library,
it
can
be
pure
code
without
any
library
it
can
be.
You
know,
plus
a
black
box
which
sends
the
request
and
all
it
does
it
just
takes.
It
can
be
your
own
implementation,
all
it
does
whatever
you
call
it.
The
final
output
will
be
to
add
some
headers
to
the
outgoing
request.
D
B
To
do
this,
it
should
be
when
you
try
to
debug
that
you
will
see
that
when
the
http
creates
a
new
span,
it
checks
for
the
context
and
the
contact
is
doesn't
exist,
so
it
creates
a
new
span
that
is
not
bound
to
anything
and
the
outcome
of
this
one.
You
will
have
two
groups
of
spam
that
are
not
connected
to
each
other,
even
though
everything
is
like
coming
and
all
going
at
the
same
time
with
the
same
data,
so
it
they
should
be
connected.
C
So
I
I
think
the
the
core
issue
here
is
actually
what
matt
brought
up
earlier,
which
is
that
the
open
tracing
library
doesn't
have
concept
of
an
active
span.
I'm
not
that
familiar
with
open
tracing,
but
is,
do
you
mind
expanding
on
that
a
little
bit
matt?
But
I
think
the
issue
is
that
when
you
call
the
open
tracing
shim
to
create
a
span,
it's
not
being
set
as
active
on
our
context.
So
when
you
call
an
outgoing
request,
there's
no
span
in
there
was
it.
Was
that
what
you
were
saying.
A
Yeah
and
like
I'm
quite
familiar
with
open
tracing
ruby,
I
my
first
kind
of
introduction
to
open
to
limit
or
open
tracing
javascript
was
more
recently,
and
I
was
I
was
looking
for
this
method
that
we
have
in
ruby
called
startactivespan
or
some
way
to
activate
a
span,
and
I
didn't
find
any
of
that
in
the
js
library
and
it
seems
like
it's
kind
of
yeah.
It
seems
like
it
works
on
like
explicitly
managed
context
for
pretty
much
everything,
and
that
was
the
root
cause
that
I
was
kind
of.
A
B
A
I
think
in
general,
like
this
is
the
responsibility
of
your
observability
system
and.
A
Like
users
should
expect
that
and
they're
free
to
remove
this
manual
manual
context
propagation,
when
they're
using
these
libraries.
What.
C
Yeah,
I
I
think,
in
order
to
manage
the
context,
the
way
that
you
expected
from
ruby
matt.
So
currently
we
have
this
like
context.with
and
every
time
you
change
context
you
you
have
to
call
like
this
callback
and
it
happens
in
there's
no
way
to
modify
like
the
currently
active
context
right.
So
I
can't
do
like
context,
dot,
accept
some
key
value
and
then
context
dot
hit
key
like
I.
C
I
can't
expect
to
get
the
value
back
here
so
like
we
need
a
way
to
set
like
the
the
currently
active
context,
and
I
believe,
that's
actually
closer
to
the
way
the
context
api
is
actually
specified.
A
A
It
seems
like
the
context
is
like
the
explicitly
managed
variety
where
you
you
always
have
like
a
handle
on
your
parents
band,
and
you
always
pass
that
in
to
start
span
for
for
the
next
thing
and
all
of
like
the
all
the
things
that
do
need
to
preserve
state.
It's
like
they've
kind
of
done
it
in
like
an
ad
hoc
way.
If
that
makes
sense,
there's
just
like
not
a
standard
way
to
do.
It.
B
B
One
thing
is
using
our
instrumentation
to
instrument
any
other
stuff
like
manually,
and
the
second
thing
is
auto
instrumentation,
and
you
can't
expect
that
suddenly,
someone
who
wants
to
use
it
will
will
need
to
modify
his
code
in
many
places
just
to
be
able
to
to
to
use
correctly
in
the
context
propagation.
That's
not
the
whole
point.
D
The
context,
the
context
for
the
context,
plugin
doesn't
lose
the
context.
In
this
case
you
are
setting
the
context
manually,
it
doesn't
lose.
There
is
no
concept
of
context
for
for
for
those
libraries,
and
I
don't
think
we
should.
We
should
modify
our
or
how
we
are
operating
the
context
propagation,
because
people
don't
just
don't
want
to
adapt
to
how
how
we
supposed
to
work.
B
C
C
C
B
B
B
D
Context,
it
is,
if
you
use
open
telemetry
again
I
mean,
could
you
could
you
give
us
an
example
on
a
concrete
example
of
I
mean
in
code?
I
don't
think
I
don't
think
you
can
do
this
right
now,
but
a
concrete
example
in
code
of
how
does
that?
Does
that
look
like,
and
I
mean
the
two-
the
the
use
cases
you're-
trying
to
explain
with
two
different
servers
when
we
without
the
pen,
telemetry
and
stuff
like
this,
so
we
can
correctly
understand.
D
What's
what
you're
trying
to
fix
and
again
I
don't
think
that's
the
issues,
I'm
I'm
sure
the
issue
that
the
the
the
original
issues
that
you
linked
and
the
issues
that
I
originally
tried
to
fix
and
I
think
that's
totally
different
because
that's
that's
a
problem
with
open
territory
that
I
was
trying
to
fix,
but
yeah.
B
D
No,
no!
No,
no,
not
exactly
because
the
the
problem
of
the
guy
is
that
if
you
make
one
one
outgoing
request,
the
next
one
will
be
on
the
on
the
same
content
on
the
the
parent
span
will
be
the
the
first,
the
first
request
so
yeah.
I
will.
B
I
just
copy
paste
your
example:
sorry,
euro
yeah.
D
But
as
I
as
I
explained
on
dpr,
that's
not
the
that's
not
the
same,
that's
not
a
good
test
and
that's
really
not
the
problem
that
the
guys
wanted
to
to
fix
and
the
code
is
not
the
same.
Even
if
the
tests
are
working.
I
mean
that's,
not
really.
The
question
is
more
like.
What's
what's
what's
the
goal
of
the
pair
because
I'm
not
setting
I'm
not
getting
the
headers
and
injecting
them
inside
the
contacts
I'm
only
injecting
it
inside
the
propagation.
D
D
D
C
So
the
bug
that
this
is
fixing
is
that,
in
the
response
callback,
there
was
a
context
here
that
was
from
the
get
call
was:
is
that
the
bug
fixing
yeah?
That's
exactly
that's
so
that
anything
you
would
do
with
the
response
would
then
be
marked
as
a
child
of
that
call,
which
is
not
correct.
It
should
be
yeah,
that's
yeah,
exactly.
D
So
so
yeah,
I
think
that's
two
separate
issues
and
yeah.
I
think
I
will
try
the
the
example
that
you
link
and
try
to
understand.
What's
what's
failing
there
but
yeah,
I
really
don't
see
it
now.
C
A
Yeah,
I
think
the
the
only
other
thing
going
through
my
mind
that
that
we
could
do
to
kind
of
like
try
to
to
validate.
This
approach
is
just
kind
of
look
at
other
libraries.
Just
look
at
some
of
the
other
hotel
libraries
quickly
and
see
how
their
http
instrumentation
is
is
working
and.
B
Yeah
open
the
code
that
is
above
I
mean
you
have
to
because
it's
hidden,
no,
no
in
the
same
file.
Sorry
it's
test
here
or
above
so
there's
another
function
which
does
exactly
the
same
for
the
incoming
yeah
just
go
up.
C
A
C
Because
when
you
have
a
request
that
comes
in
the
only
way
to
propagate
context
into
it
is
through
headers,
that's
why
the
headers
exist.
But
then
once
it's
in
the
process,
it
should
be
propagated
in
the
open,
telemetry
context
and
the
in
process
context,
and
it
should
only
be
injected
once
on
outgoing.
C
C
The
whole
point
of
the
open
tracing
shim
is
that
you
should
be
able
to
call
open
tracing
apis,
but
it
calls
all
of
our
methods
under
the
hood.
So
if
we
haven't
injected
it,
nobody
should
have
injected
yet
and
there's
no
expectation
that
we
just
work
hand
in
hand
with
other
tracing
libraries
without
code
modification.
C
If
you
have
a
custom
library
that
propagates
traces,
you
can't
expect
that
it
will
just
work
nicely
with
open
telemetry
with
no
modifications,
because
there's
all
kinds
of
other
things
going
on
in
the
background
like
we're.
Creating.
If
your
system
creates
a
span
for
the
incoming
request
and
we
create
a
different
span.
C
C
You
said
this
applies
to
things
that
outside
of
open
tracing
also,
can
you
can
you
provide
an
example
on
the
on
your
pr
of
something?
You
know
the
the
simplest
minimal
use
case
that
you're
trying
to
solve
that
doesn't
use
the
open
tracing
shim
so
that
we
can
see
the
use.
You
say
it
has
nothing
to
do
with
open
tracing.
I
don't
understand
why,
like
what?
C
B
C
Yeah
I'll
look
at
the
at
the
the
shim
issue
that
you
linked
and
see.
If
it
can
be,
you
know
see
if
I
can
understand
the
issue
better,
but
we've
been
talking
about
this
for
40
minutes
and
obviously
we're
not
getting
it
too
long
valentine.
I
believe
that
your
pr
is
unrelated,
so
I
think
that
this
pr
should
be
evaluated
separately
and,
if
I'm
understanding
what's
going
on
here,
I
I
agree
that
this
is
an
issue
that
needs
to
be
solved.
A
It
did
just
drop
in
the
open
tracing
api
docs
for
javascript.
If
anybody
else
wants
to
look
over
those
and
see
if
there's
some
magical
context,
management
methods
that
I've
overlooked,
but
I
feel
like
that
is
like
ultimately
the
root
cause
to
this
and
I'm
not
quite
sure
what
what
the
solution
is.
So,
if,
if
other
brains
want
to
noodle
on
this,
I
think
that
would
be.
That
would
be
great.
C
Yeah,
I
I
haven't
looked,
you
know,
I
was
not
I'm
not
familiar
with
open
tracing,
so
I
haven't
looked
too
closely
at
it,
but
I
guess
I
will
take
some
time
to
try
to
understand
the
open
tracing
model
this
week,
and
maybe
we
can
talk
about
this
next
week
for
now.
I
think
we
can't
block
a
release
on
this
because
it
we're
not
in
agreement
that
it
even
is
like
is
an
issue
that
needs
to
be.
C
Solved
so
I
I
think
that
we
should.
We
should
release
what
we
have
and
then
pick
this
up
next
week
after
we
have
some
time
to
look
more
closely
at
open
tracing.
C
Okay,
I
did
want
to
mention.
We
talked
in
the
maintainers
meeting
this
week
about
the
async
resource
detection.
C
And
I
brought
up
the
issue
that
we've
had
where
our
resource
detection
is
asynchronous
and
it
happens
at
process
startup,
but
we
don't
want
our
tracing
setup
to
be
asynchronous
and
one
one
solution
brought
up
by,
I
think
it
was
bogdan,
was
that
we
could
have
resources
at
startup
in
the
tracer
provider,
be
synchronous
only
the
way
we
have
it
now,
but
we
could
have
some
other
async
some
other
package
or
some
other
top-level
global
api
for
asynchronous
resources.
C
And
then
the
exporter
would
like
use
that
package
to
look
for
asynchronous
resources
before
it.
Exports.
C
I
I
mean
you
could
do
it.
I
guess
in
the
in
the
processor
too.
It
wouldn't
necessarily
matter
where
it
happens.
The
processor
probably
makes
more
sense,
but
in
the
processing
pipeline.
But
the
idea
is
that
then
you
don't
have
to
have
asynchronous
resources
through
the
entire
system,
on
like
the
tracer
provider
and
the
tracer
and
the
span
and
everything
the
asynchronous
resources
would
be
an
entirely
separate
artifact.
C
C
So
I
was
hoping
to
open
that
pr
before
the
meeting
so
that
we
would
have
something
to
talk
about,
but
I
know
that
this
is
an
issue
particularly
bart
you've
been
trying
to
get
solved,
and
I
I
I
just
want
you
to
know
that
I'm
I'm
not
just
letting
this
go
nowhere.
C
I
am
trying
to
to
figure
this
out,
but
the
the
idea
of
propagating
that
asynchronous
resource
all
the
way
through
all
of
the
spans
and
everything
there's
there's
a
lot
of
overhead
involved
with
with
the
current
solution
now
also,
since
two
promises
does
not
have
to
be
created
on
every
single
news
fan
creation.
B
You
mean
we
had
discussion
like
yesterday.
We've
been
discussing
that
basically
I
would
be
in
favor
of
creating
even
the
resources
provider
and
attach
resources
once
they
are
resolved
in
the
processor,
so
don't
attach
resources
at
all
to
any
spams,
nothing.
We
could
even
simplify
this
more
and
then
in
the
processor.
You
simply
ask
the
provider
if,
if
the
resources
has
been
resolved,
if
yes,
then
give
me
cache
them,
and
then
you
know
assign
this
to
the
all
the
spans
or
metrics.
B
If
not
then
wait
until
they
are
resolved,
then
you'll
be
notified
and
then
the
resources
drink
the
just
before
they
go
to
the
exporter.
A
I
think
that's
slightly
risky-
and
I
know
there's
like
this
desire
to
have
effectively
multiple.
You
know
logical
applications,
which
means
multiple
resources
per
process,
so
that
ends
up
being
why
the
resource?
A
Why
yeah
for,
for
that
reason,
resource,
is
on
each
span
so
that
you
don't
have
to
have
like
a
separate
exporter
for
each
one
of
these
things.
A
A
However,
like
I
would
say
that
the
prototype
that
you
just
described,
daniel
does
does
sound
interesting
and
I
think
like
and
thanks
a
lot
for
for
looking
at
that
and
working
on
it.
I
feel
like
this
has
taken
like
three
or
four
different
tries
to
get
right.
But
honestly,
I
feel
like
this
is
a
problem
for
otel
in
general,
and
I
think
I
don't
think
anybody
else
knows
it
yet.
I
think
it's
a
little
bit
more
apparent
than
javascript,
so.
C
Yeah,
the
other
I've
talked
to
the
maintainers
of
some
of
the
other
sigs
and
like
java,
for
instance,
I
asked
them.
What
do
you
do
about
asynchronous
resources?
And
they
said
you
know?
Oh
we
get.
You
know
we
just
block,
and
I
then
I
said
what
happens
if
you
start
a
span
in
a
different
thread.
While
that's
blocking
and
the
answer
was,
you
just
dropped
the
spam,
which
is
in
javascript
at
least
like
not
acceptable,
because
asynchronous
is
the
only
way
to
get
them,
but
it.
C
I
guess
the
javasight
has
decided
that
that's
okay,
because
startup
is
typically
blocking
anyway,
but
we
have
no
way
to
block,
and
then
I
think
it
was
erlang.
C
The
tristan
just
said
that
they
don't
have
any
concept
of
asynchronous
resources.
They
just
don't
do
it
and
that
seemed
to
be
the
general
sentiment
from
I
think
php
said
the
same
thing
like
there's:
no,
they
hadn't
even
thought
about
the
idea
of
asynchronous
resource
detection,
so
I
think
you're
right.
I
think
that
this
is
an
issue
that
all
of
the
languages
have
we're,
just
the
only
ones
that
are
aware
of
it.
Right
now,.
A
Yeah-
and
I
feel
like
this-
oh
we'll
just
block
at
startup
work
around
like
it's.
It's
something.
Somebody's
gonna
have
an
issue
with
at
some
point,
and
I
think
that,
like
it's,
that's
that's
not
like
an
elegant
solution
to
this
problem,
but
by
any
means.
So
I
do
think
that,
as
people
run
into
this,
like
already
kind
of
having
something
that
that
works
and
having
thought
about
this
a
little
bit
like,
I
think,
there's
there's
room
to
kind
of
like
lobby
for
some
changes
at
spec
level.
C
Yeah-
and
I
did
talk
to
bogdan
about
it
and
he
said
that
it
would
be
acceptable
for
us
to
introduce
like
a
global
resource
as
long
as
it's
not
like
in
the
api
package.
So
we
can't
just
introduce
our
own
apis,
but
as
long
as
it's
an
sdk
component
that
essentially
just
makes
it
an
implementation
detail
of
the
sdk
and
that
we
shouldn't
be
to
introduce
some
global
resource
manager
of
some
kind.
C
C
A
The
best
fail
safe
is
to
update
the
spec
to
allow
for
your
solution,
and
I
don't
know
in
my
experience
that
usually
goes
pretty
well.
If
the
solution
is
pretty
decent
and
it
helps
like
it
helps
in
multiple
ways
like
it
helps
validate
that
your
solution
is
decent,
especially
if,
if
you
have
people
like
bogdan
signing
off
on
it,
you
can
usually
be
pretty
pretty
confident
that
it's
not
the
worst
thing
in
the
world
and
then
the
other
thing
is.
C
Okay,
so
I'll
I'll
open
a
pr
with
that
prototype,
and
then
I
guess,
if
we're
happy
with
the
prototype
I'll
open
a
spec
pr
to
try
to
you
know,
make
it
at
least
somewhat
official
or
officially
allowed
or
something
like
you
know,
whatever,
whatever
term
you
want
to
use,
we
only
have
a
couple
of
minutes
left
and
I
do
want
to
make
sure
that
we
cover
these
two
issues
here
so
bart
you
real,
quick
wanna.
Just
what
is
this
here.
B
B
C
And
then
I
wanted
to
mention
this
issue.
I
tried
to
solve
this
myself,
but
I'm
not
as
familiar
with
the
the
the
exporter,
the
collector
exporters.
C
I
tried
to
solve
this
by
removing
the
hex
to
base
64
calls
inside
the
transform,
but
then
that
makes
the
gr
that
that
fixes
it
for
the
json
export,
but
it
breaks
the
grpc
export.
A
Ids
used
to
be
base
64
encoded,
four
for
json
over
http.
C
And
yeah
yeah
they
were
and
then
so
now
they
want
it
to
be
a
hex
encoded
string
yeah.
So
I
was
able
to
fix
that
by
just
removing
the
calls
to
change
it
to
base
64.,
but
then
for
some
reason,
when
grpc
converts
it
to
a
byte
array
like
it's
like
grpc
expects
it
to
be
in
base64
in
order
to
convert
it
to
a
byte
array.
B
It
I
mean
because
the
issue
is
that
the
current
proto
works
like
it
was,
but
if,
if
he
was
using
the
latest
version
of
collector
and
not
sure
if
they
already
updated
to
the
latest
proto,
but
if
yes,
then
there
will
be
problems
between
data
because
they're
expecting
different
set
of
data
too.
C
Yeah,
so
I
I
updated
the
protos,
I
never
even
got
to
the
collector,
but
the
the
grpc
unit
tests
failed.
So
I
never
even
got
to
use
the
coin
I'll
push
the
broken
pr,
so
that
you
can
see
it
it'll
be
more
clear,
what's
happening
once
I
once
I
push
the
broken
piece,
but
I
just
wanted
you
to
take
a
look
at
this
if
at
all
possible,
so
I'll
I'll
mention
you
on
it
on
the
broken
pr.
When
I
push
it.
C
Sorry
to
kind
of
brush
through
the
last
ones
really
quickly,
but
we're
a
little
bit
out
of
time.
Does
anyone
have
anything
important
that
they
want
to
bring
up
before
we
go,
or
I
don't
want
to
take
too
much
extra
time
from
people.
A
C
Of
the
changes
not
of
though
not
like
you
yeah,
75
percent
of
the
deaf
of
80,
I'm
not
particularly
worried
about
that
lost
the
report.
For
some
reason:
okay,
I'm
not
logged
in
I'll
take.
A
C
In
general,
I'd
like
to
keep
the
code
coverage
as
high
as
possible.
So
if,
if
there's
missed
code
paths
that
are
like
you
know,
important
code
paths,
I'd
like
them
to
be
covered,
but
if
you're
just
like
not
covering
logging
statements
and
stuff,
I
don't
think
it's
that
it
depends
what
is
not
covered.
I
suppose.
A
I
think
that's
kind
of
one.
The
crux
of
the
issue
is
that
this
replaces
some
logging
statements
so
like
there
weren't
exactly
like
existing
tests
there.
In
some
cases
there
were
existing
tests
for
logging
statements
and
I
made
sure
to
preserve
those,
but
I
didn't
always
introduce
new
ones
for
for
some
things.
If
that
makes
sense
kind
of
everywhere,
you
used
to
see
logger.error.
You
now
see
global
error,
handler
error.
C
Yeah,
I
mean
that's
probably
fine,
but
I'll
take
a
look
at
it.
Real
quick-
and
I
think
I
already
approved
this
yeah
but
I'll-
take
a
look
at
what
specifically
is
not
covered,
and
it's
probably
fine
I'll,
just
merge
it.
If
it
is.
A
Yeah
and
if
you,
if
it's
not
okay,
just
let
me
know
yep
we'll
do.
C
Okay,
thank
you
everybody
for
your
time
and
I
will
talk
to
you
next.