►
From YouTube: 2022-05-04 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
C
Let's
get
started,
I
guess
instead
of
doing
the
issue
triage
at
the
end.
I
just
added
new
issues
into
the
agenda
here
at
the
start,
so
hope.
That's
okay,
donald.
E
C
C
All
right
so
first
issue
here
unable
to
get
current
span
with
trace,
get
span
this.
So
I
looked
at
this
a
little
bit
earlier,
gerhard
already
asked
for
a
more
specific
reproducer.
I
don't
really
see
enough
info
in
here
to
look
at
this
all
that
closely.
So
hopefully,
this
person
will.
C
I
think
it's
probably
something
along
those
lines,
a
misuse
or
something
like
that.
I
wouldn't
photo.
It
didn't
really
provide
any
setup
codes.
So
I'm
not
sure,
okay,
next
one
here
null
port
when
using
ignore
matchers
in
instrumentation
http.
F
C
And
I
added
that
already
on
the
agent
that
pr
on
the
agenda
later
for
reviews
renaming
instrumentation
library,
instrumentation
scope,
mark
you
opened
this
one.
This
is
about
the
sdk
like
export
object
in
metrics.
We
can
rename
it
but
in
tracing
we
have
to
keep
both
names
because
we've
already
released
it
as
stable
and
it
would
be
a
breaking
change.
C
So
I
think
what
we
should
do
is
add
both
in
traces
but
then
mark
the
old
one
as
deprecated,
and
then
when
we
eventually
have
a
2.0
of
the
sdk,
we
can
remove
deprecated
fields.
Does
that
sound?
Okay
to
everybody?.
A
You
can
also
assign
that
to
me.
I
would
continue
working
on
that
since
I
have
been
working
on
the
exporters
anyway
and
I'm
familiar
with
that.
C
Very
easy
one
otlp
exporter
browser
base
cannot
be
invoked
without
new,
so
mark,
and
I
looked
into
this
one
a
little
bit
actually,
the
the
comment
that
I
made
here
is
incorrect,
so
ignore
it
for
now,
but
the
the
issue
is
that
in
the
http
otlp
trace
exporter
in
the
browser
version
of
the
esm
build.
C
C
C
Exporter
base
does
not
have
the
esm
build
target,
so
it's
just
doing
the
build
source.
So
I
think
the
fix
here
is
to.
D
But
if
it's
a
base
class,
you
wouldn't
be
newing
it
up,
because
you'd
be
using
the
current.
This
right.
C
Let's
see
where
was
I
test
yeah,
so
this
does
supercall
here
and
super
comes
from
a
different
package.
So
this
is
the
trace
exporter,
but
the
super
comes
from
the
exporter
base
package,
which
doesn't
have
an
esm
target.
So
it's
just
going
to
the
regular
the
regular
source
target.
We
actually
do
build
it,
but
it's
not
included
in
the
files
array
of
the
package
json.
C
C
I
think
I'll
assign
this
one
to
myself,
since
I
think
I
have
a
fairly
good
idea
of
what's
going
on
here
and
it's
a
little
bit
nuanced.
A
Yeah,
probably
my
fault
by
by
adding
the
the
new
package
did
overlook,
adding
the
files
to
the
packet
yeah.
C
This
shouldn't
happen
because
the
trace
protocol
should
be
stable
and
this
is
proto
not
json,
so
it's
not
even
like
field
renaming.
So
I'm
not
entirely
sure
what
happened
here.
I
did
pull
the
release,
notes
for
version
43
of
the
collector
and
the
collector
can
trip
and
didn't
see
anything
that
should
have
caused
this.
C
The
reason
I
edited
the
agenda
was
to
ask
if
anyone
was
aware
of
this
happening
in
any
other
cigs
with
version
43
of
the
collector.
Has
anyone
had
problems
exporting
using
old
versions
of
the
proto
exporting
traces.
G
C
Okay,
so
I
guess
if
you
can,
look
and
see
what
version
that
was
or
if
you
remember
that
would
be
great.
If
not
I
just
looked
at
this
before
the
meeting,
so
I
haven't
had
a
lot
of
time
to
look
into
it,
but
I
was
just
hoping
that
somebody
would
have
some
idea
what
was
going
on
here
already.
C
I
know
that
our
current
exporters
are
using
very
old
versions
of
the
proto,
so
it's
possible
that
there
was
a
field
that
was
deprecated
a
long
time
ago
or
something
like
that
and
they
just
got
rid
of
it,
but
I
would
have
expected
that
to
show
up
in
release
notes
if
they're
removing
something
deprecated
or
something
along
those
lines.
C
So
I'm
really
not
sure
what's
going
on
here.
Is
there
anyone
that
feels
like
they
want
to
be
assigned
this
issue,
like
they
understand,
what's
going
on
here
and
want
to
look
into
it.
C
A
B
G
Yeah,
I
think
it
was
fixed
in
49.
It
looks
like
I
don't
know
which
one
it
broken,
but
they
fixed
it
in
49..
G
Oh,
that
wasn't
48.
Wasn't
it
yeah.
C
A
F
And
while
we
talk
about
it
and
there's
also,
the
compatibility
of
the
json
format
with
new
exporters
and
collectors
mark
did
some
research
on
that
and
he
found
found
out
that
old
collectors
when
they
receive
a
field
name
in
porto
which
they
do
not
anticipate.
They
reject
the
the
message.
F
C
Awesome,
I
think
when
we
upgrade
the
protos,
it
will
still
work
because
the
collector
accepts
instrumentation
library
and
instrumentation
scope,
so
it
should
be
okay,
but
the
issue
is,
if
you
send
both
fields
so
that
the
specification
suggests
that
you
send
both
fields
in
order
to
be
compatible
with
as
many
collectors
as
possible.
But
old
collectors
fail
if
you
send
the
new
field
to
them.
A
C
F
F
C
Yeah
yeah,
so
I
I
talked
to
mark
about
that.
The
the
solution
is
to
update
the
collector
person
to
be
less
strict
to
not
drop
the
whole
message.
So
I
already
volunteered
for
that
issue
on
the
collector
and
working
on
that
it
happens
in
like
a
dependency
of
a
dependency.
Unfortunately,
so
it's
like
pretty
deep
down
in
the
collector,
but
it
should
just
be
an
option.
So
it's
not
that
bad
to
fix
it.
C
I
wanted
to
talk
again
about
dropping
support
for
older
node
versions.
Last
time
we
talked
about
this,
this
specification
pr
wasn't
merged
yet,
but
now
it
is
so.
I
think
we
should
make
a
policy
here
and
stick
to
it.
C
C
That
would
mean
dropping
support
for
node,
8
and
node
10
today
and
dropping
support
for
node
12
in
roughly
a
year,
and
this
would
be
for
the
sdk
only
for
now
see
a
thumbs
up
from
amir
and
mark.
I
suspect
ronno
is
also
happy
with
this
okay.
C
So
if
that's
the
case,
I
think
I
already
commented
that
on
the
issue.
C
Yeah,
so
why
don't
the
two
of
you
just
for
the
public
record?
At
least
you
know,
put
a
comment
or
a
thumbs
up
on
this
issue.
I
will
assign
this
to
myself
and
get
this
done
today.
C
And
for
what
it's
worth
dot
net
has
already
done
this,
so
you
can
see
an
example
here
they
dropped
support
for
net
five
and
they
made
it
a
minor
version
bump.
There
were
a
handful
of
prs
included
in
this.
C
We
still
have
the
open
telemetry
community
day,
I'm
just
bringing
it
up
again,
I'm
not
sure
who
all
is
planning
on
being
there,
but
I
am
probably
I'm
gonna
book
my
ticket
for
that
this
afternoon.
Actually,
I
still
have
the
google
form
here
for
submitting
a
talk,
but
I
believe
yeah.
E
C
Deadline's
already
passed,
so
if
you
have
a
talk
idea,
you
can
give
it
a
shot,
but
I'm
not
sure
nothing
else
really
to
say
about
that.
Is
there
anyone
here
that
that
is
definitely
planning
on
going.
C
Excited
to
see
people
svetlana,
do
you
want
to
talk
about
this.
H
C
H
I
think
I
might
actually
just
put
my
question
on
hold
only
because
I
found
like
three
or
four
issues
talking
about
that
and
I
want
to
gather
everyone's
thoughts
about
this
hotel
trace
exporter
option
to
set
up
a
default
exporter.
I
feel
like
it's
been
talked
about
for
the
last
year,
so
I
just
want
to
gather
all
the
thoughts
and
then
put
them
in
a
in
one
place
and
then
ask
my
questions.
So
let's
just
skip
it
today.
Sorry
about
that.
B
B
The
problem
was
like
passing
passing
the
unresolved
resource
through
as
like
a
promise,
so
I
made
a
prototype
taking
a
different
approach
which
would
instead
have
a
set
of
resources
that
resolve
asynchronously
inside
of
the
resource.
B
B
So
I
I
haven't
been
able
to
get
the
tests
passing
completely
mainly,
I
think,
because
some
of
the
otp
exporter
tests
are
a
little
brittle
with
they're
using
set
timeout,
but
otherwise
it
seems
to
be
working.
Okay,
if
you
go
to
like
the
resource
file
at
the
bottom,
you'll
see
what
I
did.
B
C
B
They
resolve
yep
exactly
and
then,
when
you
merge
resources.
Basically,
you
have
to
compose
the
promises,
which
is
a
little
dirty.
It
could
probably
be
done
more
cleanly
if
we,
if
we
keep
like
a
list
and
then
just
promise.all
them
at
the
end.
Instead
of
building
like
a
tree
of
promises
here
or
kind
of
like
a
linked
list
of
promises,
but
yeah
the
the
other
thing
is,
if
you
go
to
detect
resources
and
the
sdk
like
the
node
sdk.
B
You'll
see
that
now
this
doesn't
actually
block,
but
I
kept
the
the
old
detect
resources
as
as
an
async
function.
So
it's
not
like
a
breaking
change
in
terms
of
the
api,
like
you
shouldn't
it
shouldn't
break
anybody,
for
I
think
just
the
resource
package
is
stable
and
yeah
that
shouldn't
break
anybody,
but
it
does
sort
of
change
the
behavior
subtly.
B
If
you're
using
the
old,
detect
resources
function,
it
still
behaves
exactly
the
same
way
if
you're
using
the
new
one,
then
you
need
to
make
sure
your
exporters
await
or
something
awaits
the
promise
before
your
export
gets
called.
C
B
So
that
would
be
one
option,
but
in
this
draft
I
did
it
so
that
there's
just
one
resource
detector
interface
and
it
can
optionally
return
a
promise
like.
Ideally
all
of
them
would
not
return
a
promise.
They
would
instead
like
embed
the
promise
within
the
resource.
B
B
Hunt
for
it,
I
think
it's
in
this
fight
in
the
detect
resource
file
right
or
it's
in
types.
Sorry,
the
last
file
all
the
way
at
the
bottom.
C
Maintain
backwards,
compatibility
primarily
right.
You
would
expect
in
the
future
to
return
a
resource
where
the
promise
is
embedded
as,
like
the
the
whole
merged
promise
thing.
B
Yeah,
that's
right
and
then
another
alternative
would
be
making
a
sync
detector
interface,
which
only
returns
resource
and
never
returns
a
promise
and
then
making
it
a
union
of
those
two
types.
B
It
would
be
like
a
symbol
about
the
same
thing,
but
it
would
be
like
a
little
bit
cleaner
for
people
to
read.
Like
you
know,
with
linting
tools,
it
would
say
that
the
old
interface
is
deprecated,
for
instance,.
C
Got
it
okay,
so
then
exporters
and
spam
processors
both?
So
if
I,
if
I'm
running
a
spam
processor
for
instance,
and
I
need
to
read
the
resources,
then
I
should
also
wait
await
it.
But
if
I
don't
need
to,
then
I
just
don't
bother
yeah.
I
think
I
like
this
idea.
You
said
you're
having
a
hard
time
getting
the
tests
to
pass.
B
It
moves
that
into
a
promise.
So
until
the
next
tick
happens
in
node
it
won't,
it
won't
work.
It'll,
look
like
the
promise
hasn't
been
enqueued,
like
I'm
able
to
make
the
test
pass
if
I
sort
of
hack
them,
but
I
feel
like
it's
better
better
way
to
go
about
this.
C
Okay,
I
will
look
more
closely
at
it
than
I
don't
think
I
can
really
look
closely
enough
at
it
while
we're
on
the
call
to
give
you
an
intelligent
answer,
but
I'll
look
at
it
after
the
meeting.
B
Yeah
yeah
no
worries.
This
is
mostly
just
to
get
feedback
at
this
point
like
if
people
think
this
is
a
good
way
to
move
forward.
I
think
the
original
context
was
like
for
the
auto
instrumentation
agent
experience
this.
This
pr
does
remove
like
the
away
from
the
sdk
start
function,
so
it
would
be
possible
to
do
the
entire
thing
without
blocking.
F
F
C
Yeah
I
was
actually
gonna
make
the
same
comment.
I
was
just
gonna,
do
it
on
the
pr
after
the
call,
but
I
was
going
to
suggest
that
in
this
wait
for
async
attributes,
we
wrap
this
somehow
in
some
sort
of
like
this
async
attributes
promise
in
some
sort
of
maximum.
C
B
B
That
yeah,
that
makes
sense,
I
think
the
one
other
possibility
is
like
in
the
batch
span
processor.
We
could
do
the
weight
there
so
that
we
don't
have
to
change
the
exporters
at
all
so
like
basically
before
it
calls
the
exporters
at
all.
It
would
wait
for
this
promise
to
end.
C
B
B
C
Yeah,
okay,
I'm
not
I'd,
have
to
think
about
that
a
little
bit
so
updating
the
exporters
to
call
the
weight
is
not
that
difficult.
C
But
if
and
if,
if
an
exporter
author
forgets
to
do
that,
it
could
be
really
confusing
that
only
half
of
their
you
know
only
some
of
their
resource
properties
are
coming
through
and
they
don't
really
know
why,
for
like.
Just
the
first
export.
B
C
Yeah,
I
would
almost
say
if
you
call
if
you
get
attributes
here-
and
there
is
an
in
this
promise-
is
unresolved,
then
log,
something
to
the
diag
logger.
With,
like
a
warn
like
that,
you
have
that
you're
still
waiting
on
unresolved
attributes.
Did
you
mean
to
call
waive
for
async
attributes
or
something
along
those
lines,
just
something
to
signal
that
that
something
is
possibly
wrong,
because
I
think
in
most
cases
the
first
export
will
happen
late
enough,
that
it
won't
matter
in
most
use
cases.
C
The
the
only
instance
where
I
think
this
is
likely
to
be
a
problem
is
in
stuff
like
lambda,
where
it's
like
start
up
and
shut
down
very
quickly
and
try
to
export
as
quickly
as
you
can
with
like
the
simple
spam
processor.
B
C
Yeah,
I
think
that's
a
good
idea,
I
think
just
moving
it
into
both
of
the
both
of
our
default
span,
processors
and
then
warning
if,
if
something
is
possibly
incorrect,
it's
probably
a
good.
C
Enough
of
the
way
there
that
I
think
we're
covering
we're
doing
all
we
can.
B
Cool
the
only
other
comment
on
that
was,
I
think,
florina
left
a
comment.
I
didn't
completely
understand,
if
they're
in
favor
or
against
it,
but
I
guess
because
we're
modifying
the
resource
it
was
in
the
actual
pr.
But
I
guess
because
we're
modifying
the
attributes
after
the
promise
resolves
it
sort
of
isn't
immutable.
It
sort
of
breaks
the
immutability
contract
so
like
the
alternative,
would
be
to
actually
keep
them
separate,
but
then
that's
more
of
a
breaking
change,
because
people
have
to
actually
look
into
places
for
the
async
attributes.
So.
C
That
was
that
that
was
gotten
in
us
in
another
property
and
then
always
return
that
so
essentially,
if
you
call
get
attributes
too
early
subsequent
calls
would
not
would
return
the
same
thing
all
the
time.
Then
you
would
just
retain
the
immutability
yeah.
Okay,.
C
That's
some
some
back
ends
and
honestly,
I'm
not
even
sure
you
know
I.
I
think
the
idea
is
that
the
resource
should
be
able
to
like
uniquely
identify
or
not
uniquely
identify
the
process,
but
like
a
change
or
resource
should
signal
like
a
process
restart
stuff
like
that,
and
that
that
the
immutability
is
potentially
meaningful
to
back
ends.
So
if
you
have
an
exporter
or
a
processor,
that's
not
taking
advantage
of
the
new
api
to
wait
on
the
resources,
and
you
have
two
subsequent
exports
with
two
different
resources.
C
Then
that's
potentially
a
problem,
but
I
think
it's
only
a
theoretical
problem
really,
but
I
I
think
that's
what
he's
getting
at:
it's,
not
a
blocker
in
my
opinion,
but
I'll
reach
out
to
them
since,
since
I
work
with
him
just
to
make
sure.
C
That
was
the
last
agenda
item.
Anyone
else
have
anything.
F
F
F
And
test
right
here,
yeah
here,
the
implementation
must
not
return
the
same
tracer
when
called
repeatedly
with
different
values
of
parameters
right.
So
when
people
invoke
the
get
racer,
we
have
to
return
a
different
tracer
for
different
attributes
that
are
being
sent.
So
we
use
this
logic
twice
once
forget
laser
and
the
other
place.
F
C
Yeah,
so
I
I
understand
that,
and
then
I
think
a
workaround
to
that
would
be
to
use
the
actual
object
itself
as
the
key,
so
that
even
if
two
different
attributes
objects
with
the
same
attributes
were
provided,
it
would
be.
You
know,
you'd
get
two
different
tracers
back
and
it
would
be
exported
as
two
different
attributes.
That
just
happen
to
be
the
same.
C
Then
we're
constructing,
maybe
more
tracers
and
meters
than
we
need
to,
but
I
think
that's
a
lower
penalty
than
the
serialization
and
stuff
with
meters
like
they
have
here.
It's
unspecified
under
which
conditions
the
same
or
different,
tracer
instances
are
returned
when
the
same
attributes.
You
know
when
the
same
parameters
are
used.
C
F
C
Okay,
beyond
that,
there
were
a
handful
of
new
pr's
open
this
week,
so
please
review
those.
The
crossed
off
ones
are
already
merged,
so
obviously
don't
bother
with
that.
There's
also
a
handful
of
old
pros,
mostly
the
same
ones
we
talked
about
a
week
ago.
I
unfortunately
haven't
reviewed
any
of
these
myself,
just
because
I
have
been
gone
since
the
last
meeting.
I've
been
on
vacation.
I've
only
had
one
working
day,
but
I
will
review
some
of
these.
As
I
have
time
this
week,.