►
From YouTube: 2022-12-15 meeting
Description
Instrumentation: Messaging
A
B
C
B
I
think
one
of
my
favorite
moments
was
I
was
like
brand
new
to
Splunk
and
there
was
like
a
company
all
hands
and
I'm
I'm
watching
the
the
thing
it's
like
it's
one
of
those
like
Zoom
webinars
or
something
like
that.
But,
like
you,
still
ask
questions
and
comments
and
stuff
like
that
and
I'm
sitting
on,
like
a
couch
and
my
yubiki
gets,
pressed
and
so
like.
Just
complete
gibberish
gets
sent
to
everyone
across
the
entire
company.
C
I
remember
when
they
were
rolling
out
UB
keys
to
people
at
Amazon
right
everywhere.
Everybody
at
Amazon
is
supposed
to
get
on
right
and
for
the
next.
Like
two
months,
there
was
enough
of
the
the
long
presses
where
it
went
into
everywhere
in
all
chats
anywhere
they're
there
for
the
chat.
B
C
B
That's
that's
kind
of
how
mine
is
now
as
well.
It's
like
I
mean
when
it's
set
up
like
this,
but
when,
like
the
laptop
sitting
on
like
my
lap
or
something
like
that,
it's
like
right
next
to
my
leg,
like
that's,
not
ideal,
yeah
I,
don't
have
to
contend
with
that
too
much
anymore.
I
don't
go
to
the
office
or
even
fly
in
anywhere,
so
yeah.
C
Now
that
we've
been
acquired,
they
do
technically
I'm
part
of
the
service
now
office
in
Texas,
which
is
in
downtown
and
I've.
I've
heard
it's
nice,
but
I
I
even
have
reservations
of
like
getting
a
badge
because
I'm
like
I,
don't
want
any
kind
of
expectation
that
I
will
be
in
that
office
and
deal
with
the
you
know.
45
minute
commute
I,
don't
ever.
B
I
really
don't
blame
you
that
makes
sense.
I.
C
Mean
I
was
hired
as
a
fully
remote
person
before
they
even
required
by,
like
you
know
a
week
or
two
or
something
like
that.
Yeah.
C
C
What
I
one
of
the
last
teams
that
I
worked
on
that
was
like
semi-remote
I
found?
What
was
nice
is
if
we
did
like
we
scheduled
once
a
month
that
there
was
there
was
a
week
or
or
it
was.
It
usually
ended
up
being
like
three
to
four
days
of
stuff
of
like
we
wanna
like
you,
know,
whiteboard
out
and
design
stuff.
B
Yeah
I
think
that's
probably
the
best
way
to
do
it.
Let's
see
because
it's
also
like
you
have
team
members
who
are
super
motivated
to
have
like
connecting
and
communication
side.
So
it
helps
kind
of
The
Best
of
Both
Worlds,
I,
guess.
B
Yeah
I
guess
so.
Like
I
didn't
know,
it
was
going
to
show
up
but
I
guess:
I
forgot,
Evan,
Aaron
and
Tyler
cool,
let's
jump
into
it.
Then
I
can
share
my
screen
here.
A
B
You're
up
first
talking
about
the
code
owners
PR
here.
C
This
was
something
that
was
proposed
a
little
over
two
weeks
ago
in
well.
It
was
proposed
a
while
ago,
but
it
was
acted
on
about
two
weeks
ago,
as
the
first
step
of
of
getting
of
getting
granular
control
of
the
contrib
repo
and
potentially
just
deprecating
stuff.
So
we
said
we
would
go
two
weeks.
C
If
you
look
at
the
changes,
it's
literally
just
add
all
of
our
mod
files
to
or
everywhere
there
there's
a
mod
file
to
the
code
owners
page.
So
that
was
the
that
was
the
intent.
That's
what's
here,
you'll
notice
that
there's
a
number
of
they're,
mostly
like
HTTP
routing
libraries
that
do
not
have
any
owners
volunteered.
C
So
yeah
I
just
wanted
to
make
sure
we
had
eyes
if
we
can
get
more
approvals.
B
A
A
C
B
Think
so
as
well,
here
I
think.
That's
probably
what
we
want
to
do
as
well.
I
think
that
they
also
have
yeah,
because
I
was
asking
Anthony
about
this
interesting
to
have
single
people
as
well,
but
Anthony
was
saying
that
there's
like
GitHub
wants
to
do
some
special
things,
but
if
you
don't
have
right
access
then
like
it
can't
really
do
certain
things,
so
it
like
kind
of
just
I'm
trying
to
look
I,
don't
know
how
to
test.
B
If
this
is
bad
but
but
yeah
like
the
idea
was
like
you
didn't,
have
to
be
a
an
approver
here,
but
you
did
have
to
I
think
be
a
member
like
you're,
saying
David,
so
I
I
think
that
we
should
just
try
to
mirror
that,
because
that's
kind
of
the
goal
is
to
have
some
sort
of
ownership.
I,
don't
think
it
needs
to
actually
be
a
there's
chicken.
That's
a
great
name!
Yeah
I
I!
Think
that's
that's
what
we
should
do.
I,
don't
know
how
to
open
this
up.
A
A
B
Yeah
I
think
that
asking
for
approvers
and
maintainers
first
is
the
right
way
to
do
it,
but
I
don't
think
it
should
be
limited,
especially
if
there
are
like
you
know,
quote-unquote
experts
in
the
fields
of
each
one
of
these
packages.
The.
A
Other
thing
I
might
do
would
be
to
find
the
people
who
contributed
to
each
one
and
just
asked
them
explicitly
if
they're
willing
to
be
approvers
for
it,
they
may
not
be
CCD
on
any
of
these
yeah
issues
and
stuff.
B
That's
I
think
what
I
did
here
for
Josh
but
I,
don't
know
what
happened
to
that
comment.
C
B
Because
I
know
like
Bogdan,
was
the
developer
in
this
this
that
this
would
be
I
know
if
there
would
be
people
that'd
be
very
mad
if
the
year
about
sampler
went
away,
but
nobody's
stepped
up
for
it.
So
I
I
think
that's
a
good
one,
but
things
like
like
Vigo
I,
honestly
think
that
we
had
AWS
interns.
Add
this
and
like
I,
don't
think
anybody
really
maintains
it
anymore.
B
B
A
C
Mean
we
can
get
authors
by
directory
through
git
right,
but
I
I
can
take
that
as
an
action
item
in
the
new
year.
But
I'm
not
going
to
be
here
the
rest
of
the
year.
So.
B
Okay,
yeah
and
comment
so
that
effects.
C
But
I
will
also
say
like
this
does
not
necessarily
start
deprecating
anything.
That's
that's
the
next
step
in
what
we're
gonna
do.
C
A
B
Yeah
I
think
that's
fair,
so
it
will
in
that
case
David.
Does
it
make
sense
to
just
merge
this
well
I?
Guess,
there's
only
one
approver
but
merge
this
and
then
just
create
issues
for
all
the
unknown
ones.
C
B
Yeah
all
right
I
mean
I'm
on
board
with
that
we
do
need
another
approver
here,
but
other
than
that
I
think
that's
fine!.
A
B
Not
going
away
tomorrow,
I
imagine
yeah
they're
pretty
overworked
as
well.
Thank
you,
yeah,
okay,
I
think,
that's
fine,
then
just
emerging
is
about
that
being
updated,
but
I
do
think.
We
need
another
approver
here
which
I
think
since
it's
a
code
on
our
needs
to
be
Anthony
right.
C
B
I
think
so
I
think
I
think
yeah
I
think
with
this
approval.
It
satisfies
the
change
to
the
code
owner's
file,
so
it
just
needs
to
be
a
community
one.
Somebody
else
needs
to
approve
this
okay
and
then
yeah
the
next
steps
I'm
guessing.
B
Could
you
update
this
issue
then
here
Aaron
with
kind
of
like
what
the
next
steps
are
once
this
is
merged.
C
I
can
I
can
start
yeah,
okay,
cool.
B
Yeah
I
think
on
with
that
I
kind
of
adds
context
to
the
next
few
issues.
I
think
that's
kind
of
a
common
pattern,
I'm
I'm
here
next
week,
but
I,
don't
know
I.
Imagine
most
people
are
become
less
and
less
available
towards
the
end
of
the
year.
I
am
out
as
well
the
last
week
of
the
year,
so
yeah
I
wanted
to
kind
of
touch
base
on
kind
of
like
next
released
stuff,
but
yeah
I'll
pause
Aaron.
B
Is
there
anything
else
we
want
to
talk
about
with
the
rest
of
these
PRS,
okay,
yeah,
so
the
next
release,
if
I'm
not
mistaken,
this
is
a
big
factor
that
we
wanted
to
get
out.
B
That's
the
sense
of
conventions,
in
fact,
I
think
outside
of
this
documentation
and
Teresa
provider,
functionality
change,
that's
it
first
related
for
the
one
e112
release.
This
has
been
open
for
a
while
and
it
is
big,
but
it's
also
blocking
all
I.
Think
of
these
are
the
ones
it
resolves.
This
issue
I
didn't
want
to
address
this
issue
until
this
has
merged
I.
Think
there's
three
other
semantic
convention
packages
that
need
to
be
generated
after
this
one.
B
All
of
which
I'm
I'm
like
happy
to
address
because
I
know
that
it
takes
context
to
understand
it,
but
the
thing
is
like
this
is
blocking
all
of
it
so
like
unless
we
can
get
this
merged
or
I
can
get
some
feedback
because
to
understanding
how
to
change
this
or
change
the
approach
to
merging
this
like
I,
we
need
to
I
think
understand.
This
is
blocking
the
release.
B
So
just
a
heads
up,
if
you
have
some
time,
take
a
look
at
this
there's
a
lot
of
changes
here,
a
lot
of
it's
code
generated,
but
there's
still
also
a
lot
of
code
changes
to
I.
Think
parse,
especially
around
this
new
API
for
the
semantic
conventions,
splitting
HTTP
conventions
and
internet
conventions,
for
what
the
specification
requires.
So
it's
not
I
wouldn't
say
trivial
to
go
review
this
and
I
understand
it.
I'm
also
open
to
different
ideas
to
ease
that
process,
but
yeah
I
I
would
appreciate
more
reviews
on
that.
B
B
Let
me
see
if
I
can
check
the
calendar,
well
he's
not
on
the
maintainer's
calendar
as
being
out,
but
that
doesn't
mean
too
much
if,
if
we
could
get
the
semantic
convention
stuff
merged,
I
would
like
to
get
a
release
out
next
week,
just
because
it
would
be
the
final
one
of
the
year
and
it
would
be
about
a
year
or
a
month
cycle
since
the
last
one
I
don't
know.
B
If
it's
realistic,
though,
given
kind
of
the
the
progress
we've
seen
on
the
semantic
convention
stuff,
so
just
kind
of
asking
other
people's
opinion
on
that.
C
I'll
say:
I
do
not
have
Cycles
well,
I
won't
be
here
to
actually
make
the
release,
so
I
cannot
contribute
to
that
and
I
think
I've
done
as
much
as
I
can
to
get
the
semantic
convention.
Yeah.
B
It's
just
it's
just
I
would
need
contributions
and
reviews.
I
have
no
problem
making
the
release,
but
I
would
need
Anthony
around
them
to
approve
it.
So
I
guess
I'd
like
to
sync
with
him
after
the
meeting.
Okay,
so
then
I've
got
PR's
associated
with
the
metrics
API
changes.
B
I
wanted
to
talk
about,
but
first
just
kind
of
a
follow-up.
From
last
week
we
talked
about
this
in
add
Json
encoder
to
the
standard.metrix
exporter
that
ignores
timestamps
and
Aaron
opened.
This
group
of
Concepts
PR
here
I
wanted
to
ask
as
a
follow-up.
Does
this
mean
that
we
can
move
this
to
a
post,
ga
based.
C
On
these
changes,
I
think
so
like
there's
something
that
kicked
off
the
race
which
I
did
not
go
and
try
and
solve,
but
somebody
were
to
take
that
and
solve
that
I
think.
C
Yeah,
the
race,
the
test
race
fail,
I
I,
don't
I,
I
did
not
I
honestly
did
not
look
at
it
at
all.
Okay,
but
if
that
can
get
solved,
then
yeah
I
think
that,
honestly,
this
could
close
this
issue
right
but
yeah,
but
but
for
where
it
should
be
scoped.
It
should
definitely
be
scoped
as
after
GA,
because
this
can
be
solved
like
this
is
kind
of
a
demonstration
of
this
being
solved
without
changing
the
API
and
that's
why
we
wanted
to
have
it
pre-ga
right.
B
Okay,
cool
all
right,
so
that
was
kind
of
a
follow-up
on
that.
Then
next
on
the
agent
I
had
allow
multi,
Israel
callbacks
to
be
unregistered.
This
is
an
API
change
for
the
metrics
portion
or
metric
signal.
B
B
So
this
adds
a
proposal
change
that
was
in
here
with
this
there's
a
few
different
things:
some
sort
of
registration
and
do
you
have
an
under
register
method
on
it?
This
needs
reviews,
I,
think
I've
addressed
everything.
You've
said
Aaron
in
this
one,
so
I
don't
know.
If
there's
anything
else,
we
need
to
take
a
look
at
one
of
the
things
is:
there's
testing
I
added
some
testing,
so
that's
on
there.
B
Oh,
this
stupid
link
thing
all
right.
This
also
needs
to
get
fixed,
okay
and
then
remove
the
metrics
instrument
API.
This
is
another
one
that
I
guess.
It's
got
two
purposes,
but
it's
got
an
objection
here
from
Aaron
talking
about
the
API.
C
Yeah
my
contention
is
that
I
don't
think
that
we
need
to
change
our
interpretation
of
the
of
the
specification
right
we
built
this.
We
went
through
Community
Feed
backgrounds
around
that
we
accepted
that
this
interpretation
was
simpatico
with
what
the
specification
says.
I,
don't
believe
the
specification
that
at
least
those
lines
that
were
referenced
were
changed
since
we
built
the
original
API.
B
Well,
to
be
clear,
I
want
to
point
out
that,
like
we
built
this
API,
my
approval
for
this
API
came
with
the
assumption
that
the
person
who
wrote
this
API
reviewed
the
specification
and
made
sure
it
was
compliant.
That
was
based
on
the
assumption
that
a
person
also
was
an
author
of
The
API.
Then
I
went
back
and
I
read
the
API
and
I.
Don't
agree
that
that
was
done.
B
C
B
So
I
I
do
think
that,
like
the
thing
that
changed
is
that
we
have
to
validate
the
API
to
get
it
into
GA
and
we
started
the
validation,
processor,
I
did
and
I
looked
at
it
and
I
said
I.
Don't
think
that
was
to
the
spirit
of
what
the
API
was
trying
to
say
here
and
I
think
that
it
was
a
mistake
to
add
it.
In
the
first
place.
C
B
Yeah
that
wasn't
clear
to
me
what
what
you
were
asking
for
here,
but
that
that
is,
that
is
definitely
a
little
bit
more
I
understand
now
what
you're
saying
yeah,
and
that
was
that's
definitely
the
case
where
I
don't
think
that,
like
it
wasn't
like,
like
my
condition
on
US
accepting
this
was
that
it
was
that
it
was
compliant,
but
it
wasn't
in
my
reading
of
the
specification.
I
didn't
read
this
part
of
the
specification.
B
I
guess,
which
again
is
probably
my
own
fault
and
I
should
have
done
it,
but
that
being
said,
like
I,
do
want
to
make
sure
that
we
catch
this
before
it
goes
out
because
to
your
point
also
with
like
the
Builder
pattern,
I
think
that's
like
a
good
point.
B
I,
don't
know
if
it's
compliant
with
the
specification,
but
the
thing
is
like
I,
don't
want
to
put
us
in
the
into
a
corner.
That's
also
with
Java
and
potentially.net.
Here,
saying
that,
like
you
know
like
technically,
some
other
ones
aren't
compliant.
So
therefore
we
don't
have
to
be
compliant.
I,
just
like
I
would
rather
like.
If
that
comes
to
term.
Eventually,
if
somebody
says
like
hey
like
this
Builder
pattern
is
not
compliant
like
I,
don't
I
don't
want
to
be
included
in
that
conversation.
I
guess
is
what
I'm
trying
to
say
here.
B
If
that
makes
sense,
I
I
definitely.
B
I,
the
PR
here,
I
I,
still
think
that
the
the
package
structure
is
very
useful
in
helping
to
isolate
things
and
I
tried
to
keep
that
I.
You
know
because,
like
otherwise,
you
have
like
this
extreme
like
overlap
of
terms
and
that
kind
of
thing
and
I
don't
think
it's
again
like
I
would
want
to
make
sure
like
we
have
a
lot
of
eyes
on
the
specification
before
we
actually
release
this
but
like
having
something
like
this
seems
to
make
sense
to
me.
B
B
I
just
put
I,
don't
know,
I'd
love
opinions
on
that
it's
a
bike
shift,
but
the
thing
is,
like
the
observable
part,
I
think
was
really
key,
because
the
specification
also
recommends,
if
you
use
that
term
here
we
don't
have
observable
in
the
name,
I
and
I.
Don't
I,
don't
know.
If
that's
a
problem.
B
That's
the
only
thing
that,
like
I,
didn't
really
want
to
address
it
in
this
PR,
but
I
do
think
that,
like
if
you,
if
you
just
kind
of
ignore
that
question
right
of
like
whether
this
needs
to
have
observable
in
the
name
in
the
package
name
or
in
the
actual
type
name,
I
think
this
is
more
in
line
with
like
that.
I
don't
like
this
is
directly
what
the
specification
is
actually
recommending.
B
We
do
here
both
in
naming
of
this
method,
as
in
it
being
a
part
of
the
meter,
and
so
like
I,
don't
know
this
seems
the
most
authentic,
while
still
providing
us
with
some
sort
of
parsibility
of
like
packages
and
having
you
know
in
another
PR.
It
also
splits
options
where
those
options
then
don't
become,
like
you
know,
also
N64
observable
counter
option
or
something
like
that
where,
like
I
think
would
have
to
be
the
case.
B
B
Right
right,
so
that's
why
I
think
this
is
like
a
happy
medium
where
it's
like
I
think
this
is
very
authentic
to
what
the
specification
is
saying,
but
it
also
still
provides
that
parcability
of
the
documentation
it
doesn't
get
away
from,
like
your
credit
systems
like
Bogdan
saying
like.
B
Why
do
you
have
so
many
packages
but
like
I,
think
that
that's
I
think
that
is
a
part
of
the
style
of
decision
that
we
made
nine
months
ago
or
further,
where
we
were
saying
like
yeah,
but
I
think
that,
like
to
the
new
uninitiated
user,
it's
helpful
to
have
this
package
demarcation
and
to
help
readability
and
documentation.
So
I
think
that
that,
like
is
a
decision
that
I
I
want
to
promote
and
keep
going
forward.
B
Okay,
anything
else
we
want
to
talk
about
this
one
I
I,
also
I
I,
definitely
appreciate
the
feedback
on
that
and
I
didn't
realize
the
the
actual
question
here,
but
thanks
for
clarifying
that
Aaron,
that
makes
a
lot
of
sense
to
me.
Thank.
B
Well,
I
did
I
didn't
know,
I
was
like
kind
of
confused,
but
now
I
understand
what
that
what
this
sentence
meant
so
yeah,
okay,
yeah
sure,
okay
cool
the
next
up,
yes,
is
splitting
metric
instrumentation
configuration,
which
I
think
is.
This
kind
of
is
goes
back
to
we're.
Adding
callbacks
and
those
callbacks
are
then
also
requiring
option
types
to
be
split
across
the
instrument.
So
this
is
where,
like
having
that
packet
structure
becomes
really
helpful.
B
One
of
the
the
remaining
things
that
we're
we're
talking
about
here
is
if
the
callbacks
should
return
an
error
or
not,
and
the
pr
actually
does
address
or
does
return
an
error.
Also,
this
isn't
accurate.
Oh
it's
updated.
Yet
there
was
a
really.
B
Yeah,
yes,
is
this:
it.
B
Observer
type
that
the
Callback
actually
will
pass
in
and
that's
directly
the
instrument
that
it
can
be
updating,
which
I
think
is
a
positive
change,
so
it
was.
It
should
be
updated
to
have
this
if,
if
you
hadn't
taken
a
look
yet,
but
the
the
remaining
issue
is
that
it
still
returns
an
error
and
the
open
question
is:
there's
no
responses
to
these
errors
except
to
log
it
and
that
it
provides
instrumentation
authors,
some
sort
of
like
impetus
to
handle
their
errors
and
to
to
feed
them
in
another
way.
B
The
thing
that
I
wanted
to
point
out
was
that
I
think
that
there
is
a
way
for
us
to
funnel
these
errors
eventually
back
to
the
operator
of
the
code,
meaning
that
the
instrument
station
author
can
produce
errors,
and
then
the
operator
can
look
at
those
errors
and
decide
if
they
want
to
log
them,
drop
them
or
take
preventative
action,
and
I
was
thinking
about
this
like
if
there
ever
is
going
to
be
a
situation.
One
of
the
things
I
wanted
to
kind
of
like
point
out
is
like
take.
B
For
instance,
like
say
you
write
instrumentation
to
check
like
a
Bluetooth
demon
or
something
like
that
right
and
that
Daemon
itself
starts
to
to
barf
up
some
sort
of
Errors
right.
If
the
interpretation
author
originally
had
that
error-
and
they
just
said
like
well
like
I-
don't
know
what
to
do
with
this
and
I'm
trying
to
collect
so
I'm
just
going
to
send
this
up
through,
like
the
error
handling
pipeline
or
the
login
Pipeline,
and
the
operator
takes
a
look
at
both
of
those
pipelines
and
goes
like.
Okay,
cool
I
got
this
error.
B
I
know
the
Bluetooth
Daemon
is
like
in
a
bad
State
I'll.
Try
to
resolve
that
by
like
turning
it
right,
I'll,
try
to
restart
the
Bluetooth
name
and
to
see
if
I
can
fix
that
the
problem.
There,
though,
is
that,
like
you,
have
no
idea
in
that
error
handling
pipeline
what
collection
cycle
that
error
is
associated
with
like
there's,
that's
actually
one
of
like
the
big
reasons.
I
think
the
error
handling
pipeline
is
a
problem
is
because
it
becomes
super
asynchronous
and
so
like.
B
B
So
it
starts
spewing,
more
errors
and
then
all
of
a
sudden,
you
end
up
in
these
Loops,
where
every
five
Cycles
or
so
like
you're
you're,
causing
some
sort
of
churn
because
you're
resetting
the
the
Bluetooth
name
and
but
the
problem
is
like
if
you
pass
this
up
through
the
pipeline
and
that
pipeline
can
say
like
directly
like
hey,
like
I,
got
one
this
error
or
this
this
collection
cycle
and
you
can
go
okay,
cool
I'll,
reset
it
and
then
retry,
The
Collection
cycle,
and
you
don't
have
any
like
ambiguity.
C
The
agent
doing
the
collecting,
which
is
either
the
periodic
reader
or
I,
don't
know
your
your
your
Prometheus,
collector
or
or
whatnot
right,
whatever,
whatever
the
reader
is,
those
have
to
be
aware
and
linked
together,
whereas
I
would
expect
the
instrumentation
to
be
doing
like
asynchronous
instrumentation
to
be
doing
observations
about
something
and
it
shouldn't
be
in
the
monitoring
platform
to
do
the
reset.
That
should
be
something
external
to
the
monitoring
platform,
so
like
just
this
kind
of
set
the
scene
of
this
there.
C
There
are
three
players
in
this
in
this
game:
there's
the
instrument
and
the
instrument
author,
the
SDK
Us
in
particular,
and
then
finally,
the
last
person
that
could
see
any
of
these
errors
would
be
the
reader
right
and
what
I
would
not
want
to
co-mingle
is
the
current
SDK
has
one
error
that
it
produces,
and
that
error
is
that
the
context
failed.
So
there's
no
data
within
returned
with
this
data.
C
On
the
other
hand,
if
the
instrument
author
includes
errors,
the
current
proposal
is
to
commingle
them
with
the
context
error.
If
there
is
one
and
then
I
don't
know
how
that
is
able
to
signal
to
the
reader
who
initiated
the
collection,
whether
or
not
they
sh
what
kind
of
action
they
should
be
taking,
whether
they
need
to
check
the
context
is
closed
itself
and
continue
on
so.
B
B
That
is
not
related
to
the
context
that
they
were
passed.
That
seems
like
an
error
of
the
instrumentation.
It
doesn't
seem
like
concern
of
the
SDK
like
if
you
want
to
provide
poor
errors
like
I
mean
but
I
think
I
think
the
SDK
should
be
like
this
dumb
pipeline
that
passes
them
from
the
human
that
wrote
the
instrumentation
to
the
human.
That's
running
the
code.
B
C
But
that's
sort
of
my
point
is
like
there
are
like
apparent.
We
currently
are
in
a
situation
where
there's
errors
and
then
there's
other
errors
right
and
we'll
still
be
in
that
situation.
We
can
clearly
commingle
them.
Then
the
error
becomes
less
useful
because
we
know
that
there
was
an
error
somewhere
in
the
collection,
but
we
can't
treat
the
whole
collection
as
an
error.
Yeah.
B
But
Aaron,
like
the
thing,
is
it's
like
you?
If
you
don't
pass
the
error
and
I
think
that
you
can.
This
is
what
I'm
saying
like
you
can
wrap
errors
and
you
can
have
an
error
be
disambiguated
through
these
functions
of
error
is
and
error
apps
right,
but
if
you
don't
pass
them
along
the
same
pipeline,
the
ones
that
are
not
passed
and
are
passed.
Asynchronously
are
not
traceable.
B
You
know
five
wrapped
errors
up
the
chain
and
then
it
can
say
like
hey
at
some
point.
Was
this
important
error
for
the
Bluetooth
instrumentation
returned
because
then
I
know
what
to
do
with
this
and
it's
like?
No,
it
wasn't,
or
is
this
a
context,
timeout
error,
okay,
I
know
what
to
do
with
that
as
well.
B
Like
I
mean,
like
things
is
like,
you,
can
determine
the
errors
through
a
single
pipeline
that
you're
passing
errors
through
versus
having
instrumentation
authors,
write
errors
of
no
type
to
some
sort
of
error
handling
system
and
then
the
SDK
only
producing
or
context
cancellation
errors
like
that
seems
like
now.
You
have
two
different
pipes
and
like
one
of
them
is
useful
and
the
other
is
is
like
I
mean,
might
as
well
just
throw
them
in
like
tab
null
at
some
point,
because
you
can't
really
do
anything
with
them.
C
So
my
my
problem
is
that
the
people
that
have
to
be
concerned
about
that
is
the
the
reader
author
right,
because
that's
ultimately,
who
gets
those
errors
and
I,
don't
think
like
I
I,
don't
think
that
just
combining
them
all
together
provides
a
useful
signal
to
the
reader
author
right,
like
that's.
The
the
combination
of
these
errors
is
a
worthless
thing
to
to
the
author
of
The
Reader,
because.
B
B
C
So
the
concept
for
me
is
that
when
the
context
is
canceled,
we
don't
return
any
data
because
further
down
the
processing
line,
that
should
be
also
canceled
as
well.
Right.
B
I
mean
that's
true
right
right,
so
like
again
like
that.
Doesn't
change
so
like
if
some,
if,
if
you
get
an
error
from
the
Bluetooth
system-
and
you
get
that
also
wrapped
with
the
context
canceled
and
the
the
reader
goes
like
hey-
was
the
context
canceled,
oh
okay,
it
was
I
need
to
just
not
return.
Anything
and
I
need
to
not
export
anything
so
like
it
can
handle
that.
But
it
can
also
say
like
hey.
Is
this
also
like
once
I've
handled
that
case?
B
Is
this
a
particular
error
that
I
also
know
how
to
handle
like
there's
an
error
processing
pipeline
that
it
can
actually
do
and
then
the
default
is
like
I,
don't
know
what
this
error
is
so
I'm
gonna
just
assume
that,
like
okay
I've
got
a
partial
success,
the
context
not
canceled
I
know
those
two
states
are
exist.
I'm
gonna
go
export.
This
partial
amount
and
I'm
going
to
record
this
error
somewhere
I'm
going
to
put
that
into
the
error.
Handler
I'm
going
to
put
that
into
my
log
system.
Right
like
at
that
point.
B
B
Disagree,
so
if
you
have
somebody
who
writes
their
own
exporter
and
embeds
the
manual
reader,
that
is
exactly
what
I'm
talking
about.
That
is
exactly
the
point
where
that
author
is
saying
like
hey
I
got
this
callback
error
back
and
I
know
how
to
reset
the
Bluetooth
signal
and
I'm
going
to
go
reset
that
and
then
do
that
collection.
One
more
time.
I
do
think
that
our
built-in
periodic
reader
and
our
built-in
manual
reader
that
we
use
for
the
Prometheus
exporter.
B
Don't
they
don't
know
how
to
handle
those
signals
right
and
oh
well,
that's
not
true
like
technically
they
do
right.
They
know
how
to
handle
the
context,
cancel
signal
and
that's
to
stop
exporting
right
and
I.
Think
that
you
can
still
do
that
like
there's
nothing
in
this
change
that
will
prevent
them
from
still
doing
that
they
can
still
check
if
that
error
contains
and
unwrap
it
as
a
context,
cancel
error
or
a
context
done
error,
and
then
they
can
also
continue
to
log
those
errors
if
they're
not
like
I
I,
that
can
still
happen.
B
The
problem
is
is
like,
if
you
do
the
inverse,
where
you
don't
pass
these
errors
up.
You
run
into
this
asynchronous
error
processing
chain,
where
there's
two
different
paths
for
errors,
and
then
the
operator
is
not
given
the
option
like
yeah
I
agree
like
90
of
the
time
like
these
errors,
probably
99
of
the
time.
These
drivers
are
just
going
to
get
logged
right,
but
the
problem
is
is
like:
if
there's
that
one
percent
that
doesn't
actually
need
to
be
logged
and
be
addressed.
B
Why,
like
you
see
that
in
so
many
go
functions,
it's
like,
if
there's
a
possibility
where
an
error
could
be
resolvable,
Upstream
I
I
want
to
try
to
like,
and
even
that
like
file
system
stuff,
like
maybe
it's
trying
to
measure
file
system
I
o
and
like
the
file
is
detached.
So
you
can
do
a
remount,
or
something
like
that
like
these
are
all
these
things
that,
like
are
recoverable
errors,
that
they
could
try
to
do
for
the
next
collection
cycle.
B
B
C
B
C
B
B
This
is
this
is
in
that
pipeline,
like
I,
what
we're
saying,
if
we
say
like
hey,
don't
use
this
pipeline
go
right.
The
error
Handler
is
go,
find
another
pipeline
to
error,
handle
across
this
and
then
also
provide
ID
tracking
back
through
to
the
instrumentation
author,
and
it's
like
that.
That's
that
same
pipeline.
That's
us
like
the
SDK
should
provide
that
Pipeline
and
if
we
provide
it
in
context,
you
don't
have
any
sort
of
ID,
tracking
or
asynchronous
nature
built
in
like
it's.
It's
just
like
here
comes
the
pipe
and
I
like
I
I.
B
B
Maybe
I
don't
I,
don't
know.
Why,
though,
because,
like
your
your
point,
is
that
you're
not
able
to
distinguish
the
behavior
that
needs
to
be
performed
in
the
readers
for
callback
or
context
errors
and
I'm
saying
like
yeah,
you
are
like
I
that
that
I
still
don't
understand
that
and
like
I
don't
know
if
I'm
being
heard
into
saying
that,
like
we
were
providing
a
pipeline
for
error
handling
between
an
instrumentation
author
and
then.
C
C
That
should
be
handled
where
you
generate
the
error
right.
B
B
They
can't
when
they
can't
handle
that
error
and
they
need
the
operator
to
make
a
decision
on
what
to
do.
That's
the
problem
that
we're
trying
to
address
here.
So
those
errors
need
to
be
communicated
to
the
operator
and
they
can
be
communicated
two
ways
through
a
callback
returning
an
error
that
gets
propagated
to
the
operator
who
actually
called
for
collect
or
through
an
asynchronous
push
to
the
error.
Handler,
the
global
error
Handler
one
of
those
has
value
in
the
fact
that
it
has
the
context
for
which
that
error
was
generated.
The
other
doesn't.
C
B
Don't
think
that
the
collection,
if
I,
had
instrumentation
that
decided
to
reach
into
the
Unix
system
and
say
like
hey
system
D,
go
restart
this
statement,
oh
by
the
way
you're
on
Windows
I,
need
to
restart
it
on
Windows,
oh
you're
on
but
like
that
is
way
out
of
the
purview
of
instrumentation
authors.
That's
like
that's.
B
If
that
reader
is
owned
by
the
operator,
yeah
100
percent,
why
wouldn't
like
the
operator
is
the
one
who
sets
up
the
reader
like
I'm
the
operator
at
runtime?
Going
like
that's
cool
like
you?
Have
this
periodic
reader?
You
have
this
manual
reader
I
want
to
build
my
own
Prometheus
exporter,
and
that
exporter
has
a
manual
reader,
that's
embedded.
That
knows
how
to
handle
issues
with
this
Bluetooth
Daemon,
because
I
know
how
to
handle
them.
A
B
Okay,
so
okay,
then
like
I,
I,
think
I'm
an
operator
and
I
go
like
hey.
I
know
how
to
handle
these
Bluetooth
errors,
like
I've,
got
really
buggy
demons
right.
I
would
like
to
fix
that
on
this,
this
platform
I'm
using
there's
this
cool
instrumentation
that
provides
some
sort
of
information
around
the
statement
I'd
like
to
measure
it,
but
sometimes
it
needs
a
kick.
C
So
if,
if
they're
already
providing
some
kind
of
reader
right,
why
does
the
SDK
have
to
be
the
one
that
does
this
information
like
this
this
process?
Why
is
it?
Why
is
it
the
sdk's
responsibility
for
operating
on
all
of
the
information
that
it's
created
by
the
SDK
I
thought?
That
was
the
exact
opposite
of
what
the
SDK
was
supposed
to
do.
The
SDK
is
supposed
to
get
that
information
out
of
the
system
or
or
to
the
export
or
eventually
so.
B
Yeah
I
agree,
but
we're
talking
about
errors.
Remember
and
it
doesn't.
We
also
said
that
the
default
cases
it's
just
going
to
log
because
it
doesn't
know
how
to
operate
on
these.
But
what
I'm
saying
is
that,
like
the
default
case,
may
be
different
for
an
operator
that
has
context
and
says,
like
hey,
I,
actually
know
how
to
handle
the
Bluetooth
there.
So
when
you
give
me
this
error,
I
will
do
something
different.
B
The
default
SDK
is
like
I,
don't
I,
don't
know
what
this
instrumentation
error
is
like
I'm,
gonna,
I'm
gonna
send
this
I'm
gonna,
send
it
off
to
wherever
I
can't
if
it's
going
to
be
a
login
sister
error
Handler.
But
at
that
point
you
have
the
ability
for
an
operator
to
come
in.
Otherwise
the
operator
has
to
go
in
and
say,
like:
okay,
I
have
to
rewrite
instrumentation
I
have
to
go
in
and
like
this
instrumentation
from
this
Bluetooth
author
at
the
fork,
because
the
error
is
contained
only
here
at
this
level.
B
B
Well,
okay,
Aaron!
Does
that
mean
that
we
shouldn't
be
passing
errors
anywhere
in
our
code?
No
because
this
is
the
thing
like
eventually
like
it's
just
gonna.
You
know
in
the
tracing
system,
our
exporters
they're
gonna,
they're,
gonna
log,
it
anyway.
So
why
would
we
pass
it
through?
A
span
processor
It's
like
because
somebody
can
write
their
own
span.
Processor,
get
an
error,
that's
relevant
from
instrumentation
and
take
an
action
item
I
like
what
was
the
difference
here.
C
So,
for
me
fundamentally,
the
difference
is
errors
created
by
instruments,
aren't
necessarily
the
same
as
an
error
created
in
the
processing
of
the
pipeline,
and
my
understanding
is
that
the
readers
are
keen
on.
What's
the
air
are
Keen
to
understand
whether
or
not
the
the
processing
the
the
concept
of
processing
had
an
error,
not
necessarily
that
the
particular
instrument
had
an
error.
What
it
wants
from
the
instrument
is
whether
or
not
it
got
data
right.
B
B
B
I,
don't
I,
don't
think
so
we're
on
the
same
page
like
if
you
want
to
pass
to
you
at
some
point
in
time.
How
do
you
want
to
pass
to
you?
Do
you
want
to
pass
the
uniform
that,
like
when
I
called
collect,
I
get
a
response?
That's
the
resource
metrics
and
an
error
or
I
call
collect
I,
get
resource
metrics
and
then
it
completely
asynchronously
in
the
error.
Handling
pipeline
I
get
an
error.
B
B
B
B
B
Don't
think
so
because
if
you
send
that
collect
and
then
the
operation
that
called
that
collect
gets
an
error
can
handle,
it
does
a
retry
as
you
would
call
it
and
can
just
successfully
get
the
next
collection
cycle
to
work.
That
process
succeeds,
it
doesn't
succeed
in
the
other
situation.
It
completely
fails.
No.
B
Get
let's
go
back
to
your
example
about
the
HTTP
you
go
and
do
that
first
collection
right
and
it
times
out
that
timeout
error
is
not
sent
back
to
the
original
caller.
That
timeout
error
is
sent
through
some
asynchronous
pipeline
for
error
handling.
What's
the
caller
gonna,
do
it
doesn't
know
how
to
retry,
because
they
didn't
get
that
response.
It
doesn't
know
that
it
can
retry.
It
just
has
to
fail.
There's
no
retryability.
C
I
I'm
look
at
this
point.
We
are
arguing
in
circles
and
I.
Don't
think
that,
like
I
honestly,
do
not
feel
like
that
error
should
be
there.
I
can
still
review
it
as
if
in
the
way
that
you
intended
and
and
whatnot,
but
I,
don't
think
that
that's
the
right
approach
on
this
I
do
want
to
know.
I
know
we
only
have
two
other
people
do
either
of
you
Evan
or
David.
C
Do
you
have
any
kind
of
input
on
this
because
it
totally
could
be
that
we're
way,
Deep
In
The
Weeds
at
this
point.
B
C
No,
no
I'm,
not
blaming
you
I
understand.
We
are
very
passionate
and
we're
trying
to
to
argue
our
points.
A
C
B
A
B
B
A
B
And
that
callback
sinks,
you
know,
pulls
out
to
some
sort
of
Daemon
and
then
that
that
that's
failing
because
say
the
Damon's
failing.
Would
you
want
to
know,
as
as
the
operator
that
system
the
person
calling
collect
about
that
error
in
like,
in
the
context
of
calling
that
context
or
through
some
sort
of
asynchronous
callback.
A
A
B
A
A
C
Probing
deeper
into
this
say:
we
do
have
that
Bluetooth
setup.
What
about
if
I
wanted
to
also
what
should
we
call
it
if
I
wanted
to
also
handle
an
error
with
NFS
right,
I
want
to
remount
NFS
when
I
find
it?
How
do
I
do
both?
At
the
same
time,
though,
do
I
have
to
set
up
completely
separate
Pipelines.
C
C
B
B
B
I'm,
not
I'm
not
trying
to
really
what
I'm
saying
is,
like
you
know
like
you,
can
you
can
parse
20
different
errors
like
if
you
had
to
resolve
20
different
things
from
these?
These
errors
that
are
coming
through
and
the
errors
are
constructed
appropriately,
where
we
wrap
them,
and
so
they
can
become
unwrapped.
You
can
distinguish
all
of
them.
You
can
distinguish
a
context
error,
an
NFS
error,
a
Bluetooth
error,
a
Wi-Fi
error.
B
Like
all
these
different
errors,
you
can
say
like
I,
know
how
to
resolve
all
of
those
since
they're
also
errors
and
I
got.
You
know,
partial
response.
I
know
to
not
export
it,
because
the
context
is
canceled.
I
know
I
need
to
reset
the
Damon
for
Bluetooth
and
I
know.
I
need
to
reset
the
David
for
NFS.
Do
those
three
things
retry
and
at
the
same
time
the
original
export
doesn't
have
to
fail.
It's
exactly
like
that.
Http
call
the
original
call
to
go
and
do
an
export
is
like
I'm,
smart
enough
to
understand.
B
B
A
I
mean
I'll,
say:
I
agree
with
returning.
It
I
think
it's
almost
certainly
a
moot
point,
because
I
don't
think
anyone's
gonna
do
what
Tyler's
saying
I
think
it's
cool
that
it's
possible
in
theory,
and
that's
fine,
so
I'm
happy
to
return
it,
but
I
think
everyone's
just
gonna
end
up
sending
it
to
the
global
error.
Handler
anyways.
A
B
Some
sort
of
like
function
you
want
to
do
for
each
collect
like
you,
you
can
add
it,
but
we
need
to
make
sure
the
error
is
there
for
you
to
actually
parse.
That
error
is
the
thing
I.
C
B
C
B
Agree,
if
you
don't
put
the
error,
though
yeah
there's
is
there's
an
alternative
way
to
find
this
out.
Isn't
it
so
you
can
put
it
through
the
error
Handler,
but
that's
kind
of
the
other
side
is
like
now.
You
have
to
build
some
sort
of
ID
recognition
system,
because
the
error
Handler
is
completely
asynchronous
to
the
caller
like
when
I
called
collect.
B
C
C
A
B
You
wanted
to
make
metrics
like
those
metrics
are
going
to
be
skewed
time-wise
for
the
collection
cycle,
but
it's
not
like
the
end
of
the
world.
It
is
going
to
make
a
difference
if
it's
remediation,
that
you
want
to
try
to
do
and
I
think
that
that's
important
returning
the
era
gives
you
a
more
causal
direct
linkage.
A
A
B
So
that
being
said,
I
know
we're
way
over
time.
I
do
want
to
say
thanks
everyone
for
the
year
of
contributions
and
I
appreciate
everyone's.
This
help.
I
know
it's
only
for
people
but
yeah,
happy
holidays.
Everyone
and
we'll
see
you
all
in
the
New
Year,
okay,
okay,.