►
From YouTube: 2023-02-16 meeting
Description
Instrumentation: Messaging
C
That's
what
I
think
we
can
get
started.
Please
add
your
name
to
the.
C
C
So
yeah
cards
booked
it
here,
Carlos
put
it
here
to
give
some
context
to
what
he
wrote
here
for
people
who
were
not
attending
the
Tuesday's
back
meeting.
C
We
decided
I
think
actually
two
weeks
ago
that
we
want
to
push
for
adding
links
after
spam
creation,
because
that's
some
prerequisite
of
some
of
the
spine
structure
scenario.
Three
came
up
and
I
opened
a
PR
for
that.
This
is
this
one
which
got
quite
some
approvers,
but
also
has
some
pushback
regarding
mostly
from
the
go
go
side,
it
also
affects
others,
and
the
main
pushback
is
that
the
artists
will
break
by
adding
a
new
method
like
a
ad
link
method
on
the
span.
C
This
will
break
existing
interfaces,
so
this
is
for
languages
who
cannot
add
methods
to
interfaces
without
without
basically
introducing
a
new
interface.
So
a
new
API
version,
so
double
some
discussion
here
in
the
Tuesday
meeting
and
the
summary
I
put
here.
The
summary
was
that
before
we
push
this
further
forward,
we
we
want
to
evaluate
like
alternative
solutions
that
are
not
as
invasive
in
in
some
languages
and
the
possible
options
that
came
that
came
up
that
were
proposed.
C
This
yeah
not
having
a
separate
method
for
adding
links,
but,
for
example,
specifying
links
is
arguments
in
the
and
Method
on
the
span.
C
So
this
means
that
you
would
need
to
save
your
context
or
contexts
as
they
come
in
during
the
span
is
active
and
then,
when
you
end
the
span,
you
call
the
end
method
and
you
pass
all
the
contexts
in
that.
We
will
not
pursue
this
further,
because
here
it's
not
efficient
from
it's,
not
very
convenient
from
a
user
point
of
view.
You
have
to
store
your
contexts
and
wait
until
span
ends
to
apply
them
and
it
is
also
Josh
McDonald
brought
it
up.
C
It's
also
not
optimal
from
a
sampling
point
of
view,
because
he
said
from
a
sampling
point
of
view.
We
want
to
know
the
link
as
soon
as
basically
the
context
comes
in,
because
we
still
might.
We
still
want
to
have
the
flexibility
to
maybe
change
the
sampling
decision
on
the
span
based
on
the
link,
and
for
that
it
makes
sense
to
know
this.
This
link
as
soon
as
possible,
not
just
on
the
end
method.
C
So
we
will
not
pursue
this
further,
but
there
is
was
an
other
idea
and
that
came
already
up
before
other
discussions
in
this
group,
particularly
between
Josh
and
Luke,
Miller,
that
the
span
link
is
added
as
as
an
event,
so
you
add
an
event
on
the
span
and
that
the
event
is
a
certain
structure.
It.
It
somehow
includes
information
from
the
spam
context,
and
it
also
includes
information
that
this
event
is
supposed
to
be
a
spandling
foreign.
C
This
will
this
event
then
causes
a
link
to
p
created.
D
But
you
honestly
I
held
it
also
on
Tuesday,
but
I
didn't
want
to
disrupt
the
big
meeting,
but
would
it
mean
that
we
will
have
to
store
like
a
dress
price
ID
and
spend
ID
and
other
things
as
a
event
attributes?
D
Because
I
think
we
discussed
it
a
lot
in
the
past
and
it
didn't
make
sense
to
us
because
it
makes
everything
so
complex.
Well,
you
already
have
this
link
with
that's
supposed
to
do
exactly
that
and
that's
why
we
decided
to
drop
it,
but
on
Tuesday
nobody
seems
like
to
think
that
it's
not
correct
and
I
wonder
why.
C
I
I
think
we
need
to
show
some
Goodwill
here
and
try
to
come
up
like
with
some
at
least
propose
one
other
solution
that
people
can
pick
from
and
I
I
agree
with.
You
also
based
on
discussions
in
this
group.
I.
Think
the
this
is
the
last
option
here.
The
ad
link
method
proposed
in
this
PR.
It
seems
to
me
like
the
keenest
one,
because
it
fits
in
it,
makes
the
API
design
intuitive
I,
think
easy
to
understand
for
users
and
I
think
from
the
API
design
perspective.
C
C
That's
that
is
the
current
plan
is
now
that
the
colonel
said
he
puts
up
a
draft
PR
with
this
ad
event
and
and
then
we
can
discuss
drawbacks
of
of
this
ad
event.
Approach
on
this
PR
compare,
compare
it
to
this
PR
and
then
I
think
we
will
pick
one
or
the
other,
and
hopefully
I
would
say
we
pick
this
PR
I.
C
Think
the
the
reason
for
here
is
that
the
lb
we
need
to
show
some
like
due
diligence
and
also
kind
of
efforts
from
our
site
that
we
investigate
alternative
Solutions
so
that
we
can
then
kind
of
evaluate
and
say:
okay,
we
go
with
this
or
that
solution.
C
I
think
it's
as
much
a
technically
discussion
as
it
is
also
a
tactical
discussion.
To
be
honest,
you.
D
C
I
think
the
the
Ed
event
solution
that
might
be
I
might
be
more
important
with
this
with
this,
if
we
would
like
design
an
API
from
scratch,
but
with
the
existing
API.
Basically,
we
will
not
get
rid
of
the
adding
links
as
spam
link
objects
on
span
creation.
C
That
is
part
of
the
API
that
happens
already
out
there.
So
that
will
stay
and
basically,
with
the
add
event
method,
we
will
have
an
additional
way
that
the
link
can
be
specified.
So
a
link
can
then
either
be
this
band
link,
that's
added
on
span
creation
or
it
can
be
an
event.
Let's
add
it
later
and
I
think
that
is.
That
is
not
nice
at
all.
C
So
I
agree
here
with
you
I'm
here,
but
I
think
you
need
to
yeah,
as
I
said,
show
some
show
some
willingness
to
evaluate
additional
paths,
and
then
we
will
see
where
we
end
up,
and
hopefully
we
can
push
this
one
further.
C
I
think
we
have
quite
some
some
approvals
here
from
TC
and
CC
folks,
so
it
seems
there
is
some
some
consensus
there
that
this
is
something
that
we
should
do
at
the
links
after
span
creation,
India
I
hope
that,
after
discussing
the
other
proposal-
and
we
can
hopefully
settle
on
this.
C
Okay,
that
was
this
point
here.
What
I
would
like
to
do?
I
would
like
to
go
over
open
comments
in
the
in
the
span
structure.
C
Pr
I
mean
first
something
I
I
did
based
on
discussions
with
Tyler
on
Monday
and
also
last
week,
and
unfortunately,
it's
not
here
today,
I
made
some
changes
to
the
to
the
span
structure
to
the
pr,
mostly
in
the
in
these
visualizations,
and
what
I
did
here
added
some
text
that
describes
that
there
are
all
the
spans
that
are
more
or
less
required
to
be
created
by
these
conventions.
I
made
them
green.
Also,
the
connections
that
are
required
by
this
specification
I
made
them
in
green
and
everything
else.
C
That
is
just
here
kind
of
to
illustrate
the
overall
span
flow,
I,
I,
left
kind
of
in
the
default
color
between
my
kind
of
skin
here
is
is
black
because
often
especially
the
process,
bands
cost
confusion
and
I
try
to
make
it
clear
that
the
other
process
spans
and
also
how
they
are
kind
of
related
to
other
spans.
That
is
not
really
a
part
of
those
conventions,
and
that
is
something
that
can
then
be
specced
out.
C
Hopefully,
on
top
of
these
existing
conventions,
but
I
wanted
to
make
clear
that
those
bands
that
are
green
are
kind
of
more
or
less
required.
That
is
what
the
back
end
can
rely
on
and
the
other
spans
here
are
currently
at
the
yeah.
It
said
in
the
Judgment
of
the
instrumenters
to
create
those
bands,
and
maybe
there
will
be
conventions
in
the
future,
because
we
had
to
discussed
a
lot
about
process.
C
Bands
and
Tyler
has
lots
of
valid
points,
but
I
think
one
goal
that
we
here
have
is
here
provide
like
a
default
experience.
The
backends
can
rely
on
and
it
also
can
be
done
with
auto
instrumentation
and
yeah.
It's
I
think
with
that.
C
With
those
constraints,
it's
just
like
a
smaller
set
of
of
spans
and
or
functionality
that
we
that
we
end
up
with
so
yeah
I
might-
and
it
is
strange
hopefully
to
to
to
make
clear
that
this,
like
this
diagrams
here,
actually
include
More,
Than,
This,
spec
comments
and
a
trust
here,
edit
other
spans
here
to
kind
of
illustrate
the
Overflow
and
I
hope
that
makes
things
clearer.
B
And
I
ask
this:
is
a
rookie
question,
real
quick,
but
does
this
negate
then
the
need
or
the
the
pattern
of
context
propagation
or
is
that
still
required
in
order
to
build
the
link
and
I
don't
mean
to
derail
this
I
just
wanted
to
ask
or
if
there's
something
I
can
I
should
read
up
on
on
that
that'd
be
great,
because
my.
C
C
The
context
propagation
is
definitely
still
required
and,
okay,
give
me
a
second
we
have.
We
did
that
as
one
of
the
previous
items
that
we
achieved
here
in
this
group.
C
If
you
look
at
the
existing
semantic
conventions
for
messaging
there
is
we
added
like
a
dedicated
section
for
context,
propagation,
okay,
excellent,
so
they
discussed
Rao
kind
of
brought
into
spec
PR,
and
we
had
a
Otep
before
and
I
think
all
the
requirements
that
we
have
for
context
propagation
are
here
in
this
here
in
kind
of
a
that's,
basically,
the
the
kind
of
the
very
short
two
seconds:
okay,.
C
Regarding
the
agenda
for
the
last
two
items,
I
I
think
it
would
be
good
to
have
Luke
Miller
here.
So
maybe
we
postponed
that
to
Monday
or
to
next
Thursday,
and
maybe
today
we
can
go
over
open
comments
in
the
spanstalk
tropia
and
see
which
of
those
we
think
we
can
close
to
make
some
some
progress
there.
C
There
is
this
first
PR
from
this
first
comment
that
that
is
exactly
about
process
bands.
C
Unfortunately,
title
is
not
here
today
we
discussed
this
on
Monday
and
I,
wanted
to
ask
him
whether
his
weather
is
fine
with
with
The
Stance
of
leaving
out
the
process
bands
here
and
whether
we
can
close
this
discussion.
But
yeah
I
will
then
write
a
comment
here
and
ask
him
whether
he
still
has
his
thoughts
about
that
I
mean
here
just
wanted
to
track
with,
like
the
folks
here
in
the
meeting.
C
Do
you
have
doubts
about
the
decision
to
leave
out
process
bands
or
leave
that
out
of
scope
of
of
this
iteration?
Or
do
you
think
that
the
specking
out
process
bands
should
be
part
of
this
of
this
iteration
that
we're
doing
here.
A
I
think
it
does
make
a
good
point.
I
think
that
if
there
is
nothing,
then
people
will
do
I,
guess
whatever
and.
A
Not
sure
if
we
need
to
do
as
part
of
this
PR
or
maybe
as
a
follow-up
but
I
think
maybe
in
the
V1
I
guess
that
we
want
to
achieve.
Maybe
we
should
have
at
least
like
a
not
normative,
but
like
some
some
guidance,
I
guess,
because
then
at
least
because
like
if
you
think
about
people
they're
going
to
write,
instrumentations
I
think
it's
nice
that
they
have
some
idea
right
like
what.
A
If,
if
it's
possible
for
them
to
put
the
process,
pin
then
like
it
would
be
nice
to
see
what
name
to
use
and
and
and
all
that
stuff
so
I
think
we
could
we
we
could
do
it
I
think,
but
we
just
need
to
be
careful
that
it's
not
if
we
don't
signal
that
this
is
like
something
that
has
to
be
created
always
and
so
on.
But
it's
just
like
a
yeah
General
guidance.
I.
Think.
C
A
Think
maybe,
but
maybe
as
a
follow-up,
not
I,
guess
not
as
part
of
this
doesn't
make
sense,
I
think,
but
we
can
always
do
like
okay,
we'll
open
a
separate
PR
for
it
and
get
on
yes.
C
Sir
I
wouldn't
want
to
include
it
in
this
PR
because
it's
already
pretty
right.
A
C
And
it
gets
harder
and
harder
to
review
so
I
think
the
main
question
then,
for
this
PR
is
yeah,
whether
whether
we
think
that
what
we
came
up
with
here,
whether
that
is
kind
of
a
good,
a
good
basis
that
allows
then
adding
this
adding
process.
C
Pen
I
will
I
will
ask
Tyler
then,
if,
if
he's
fine
with
that
approach
and
if
he
maybe
can
review
this
PR
in
light
of
this
process
band
or
maybe
whether
he
can
come
up
like
with
the
draft
and
the
draft
Pro
document,
that
kind
of
describes
how
we
would
how
we
would
add
process
bands.
C
On
top
of
that,
because
I
would
like
to
see
then
as
a
probably
the
two-tiered
approach
that
we
had,
that
is
okay,
there's
the
absolute
minimum
that
always
needs
to
be
there.
That's
what
I
can
rely
on
that
would
be
this
PR
and
then
basically
there's
an
addition
on
top
of
that
that
says
yeah.
If
you
create
a
process
pen
which
is
kind
of
optional,
more
or
less,
because
not
in
all
scenarios,
you
can
do
it
or
it
will
not
be
there
in
all
scenarios.
C
But
if
you
create
a
process
band,
then
that's
how
that
should
look
like
yes,.
C
Okay,
then
I
will
I,
will
comment
here
and
yeah
see
whether
Tyler's
willing
to
to
come
up
with
a
with
a
proposal
here.
Okay
I
will
fill
that
in
after
the
meeting.
C
Here
we
have
a
comment
from
from
Bruno,
where
we
have
our
basically
our
span
types
I,
either
create
I,
think
we've
published,
create,
receive,
deliver
and
settle,
and
the
Bruno
suggests
composite
names
like
for
span
that
you
can
have
a
span
that
does
both
create
and
publish,
and
it
has
kind
of
a
combined
name
and
also
span
that
does
both
receiving
and
processing.
That
also
has
a
combined
name.
C
C
I
I
I'm
I
added
my
two
cents
here,
I
actually
think
he
says
it
would
be
a
nice
clarification.
C
I
actually
think
it
would
make
things
often
probably
even
harder
to
understand
than
having
like
combined
names
and
having
like
I,
don't
know.
Instead
of
five
choices,
having
eight
nine
ten
or
more
some
more
combinations,
some
are
like
a
individual
and
I
and
then
also
there's
the
there's.
C
The
question:
where
do
we
enter
now
in
the
might
be
receive
process,
but
then,
for
some
people
also
receive
process
settle,
might
make
sense,
so
you
might
even
want
to
pack
like
auth
or
like
three
stages
in
in
a
span
and
also,
if
you
have
it,
merge
them
together,
you
would
lose
the
possibility
to
kind
of
model.
The
the
case
where
one
operation
fails
in
the
ad
operation
does
not
yeah.
There
is
there's
pros
and
cons
here.
C
I
mean
I
was
arguing
more
like
here
on
the
side
of
of
Simplicity
and
keeping
things
simple
and
maybe
also
having
like
other
indicators,
then
the
name
for
example,
having
okay.
When
you,
when
I,
have
a
a
published
span
of
kind
producer,
then
I
already
know.
C
Okay,
that
this
is
that
this
published
span
also
includes
the
create
stage,
because
otherwise
to
create
spam
would
be
the
producer,
and
maybe
there
is
like
we
can
have
similar
Logic
for
for
other
other
cases,
but
I
I,
wonder
if
what
you
think
about
this,
this
idea
of
kind
of
I
think
composed
composed
stages
in
spans
like
well
Bruno's
address.
A
Yeah
I
I'm
not
sure
if,
if
I
see
also
much
much
benefit
for
it
and
I
also
think
it's
going
to
be
more
confusing.
Like
you
said,
yeah
like
without
without
having
real
like
examples
or
something
like
that,
it's
kind
of
hard
right
I
mean
we
can
come
up
with
different
combinations.
Like
I
said
it
probably
is
not
going
to
be
enough
anyway,
so
I
I,
think
I
I
would
vote
just
to
keep
what
we
have
today
and
and
yeah
see
how
how
things
how
things
go?
A
I
think
we
can
also
add
this
afterwards
right,
if
need
be,
I
guess,
but
that.
C
Is
also
my
stance,
I
think
we
can.
We
can
easily
add
this
later
on,
like
additional
stages,
if,
if
it's
needed,
but
if
we
start
out
with
it
right
in
the
beginning-
and
once
this
is
stable,
we
will
not
be.
We
will
be
able
to
remove.
C
I
think
it
refers
to
both
because
yeah
we
put
the
operation
name
into
the
span.
The
operation
attribute
the
value
into
the
span
name
in
some
cases.
D
So,
regarding
the
spend
name,
I
think
like
we
shouldn't
be
so
strict,
like
users,
can
have
the
the
freedom
to
try
to
to
write
anything
meaningful,
though,
as
long
as
it
has
a
local
dinarity.
But
regarding
the
attribute,
this
is
actually
a
good
point,
because
we
had
some
examples
of
like
spends.
That
represents
several
operations.
D
If
you
remember
there
was
a
guy
that
said
that
he
doesn't
want
to
create
all
those
pens,
it's
just
expensive
and
noisy
just
once
one
single
spend
that
is
both
the
receiving
the
bosses
and
I'm,
not
sure
what
this
span
should
have
for
messaging
operation
attribute.
So
maybe
we
can
have
like
an
array
of
attributes.
D
C
D
So
I
don't
know
if
you
remember
there
was
a
guy
like
a
few
months
ago,
they
joined
and
describes
this
use
case.
I,
don't
remember
what
the
system
it
was,
but
basically
what
he
said
and
I
can
relate
to
it
is
that
it
doesn't
want
to
create
all
those
spans
for
where
like
receive
and
then
process
and
then
settle,
because
it's
too
noisy
and
too
chatty
and
too
much
expensive.
He
just
wants
like
a
single
span
for
processing
of
messages
or
a
messaging
in
a
pipeline
and
and
I.
D
Remember
that
it
made
sense
and
I
think
this
use
case
will
not
be
covered
by
this
toy
structure.
Right.
C
It
it
will
not
I
mean
it
will
be
covered
in
the
sense
that
you
have
a
new
when
you
like
the
minimum
required
on
the
on
the
consumer
side
is
basically
one
span
either
you
have
a
receive
or
you
have
you
have
a
deliver
span,
so
one
of
those
two
spans
is
required
on
on
a
consumer
side
and
I
mean
if
you
want
to
go
to
minimalistic
Route
here
you
could
just
create
either
receive
or
a
deliver
span,
and
that's
it
and
just
implicitly
kind
of
covers
the
other
operations.
C
If
only
the
span
is
there,
but
I
see
also
see
your
point
that
we
say:
okay,
we
there's
still
the
option,
for
example,
is
the
receive
span?
The
question
is
Daniel.
What
does
this?
What
does
the
duration
of
this
received
span?
Actually
cover?
Is
that
trust
the
receive
operation
and
Trust?
There
is
no
spans
for
the
ad
operation
or
does
the
duration
of
these
received
span
actually
also
cover,
processing
and
and
settlement
and
I?
C
Think
that's
yeah,
that's
something
you
could
denote
with
like
just
adding
this
to
the
or
just
having
this
combined
or
array
array
operation
that
the
that
there,
you
say,
okay,
this
this
this!
This
duration
of
this
band
covers
receiving
and
also
processing.
D
C
With
the
duration,
it's
pretty
clear
with
the
semantics:
it's
gonna
be
harder
because
then,
when
you
have,
for
example,
an
error
on
this
receive
process
band,
we
don't
really
know.
Okay
did
the
receive
operation
failed.
Did
the
process
operation
fail,
I?
Think
there
it's
getting
tricky,
then,
in
terms
of
semantics,
I
think
in
terms
of
semantics,
it's
still
hard
to
keep
apart.
Okay,
what
what
belongs
to
receive
and
what
belongs
to
the
process.
I
think
many
semantic
like
many
of
the
attributes
are
shared
amongst
them
too.
C
But
but
there
are
some
there
might
then
be
yeah.
It
might
not
be
evident
but
kind
of
refers
to
what
operation.
E
Yeah,
but
in
fact
I
haven't
on
that
are
I.
Think
in
the
case
of
receive
it's
very
hard
to
combine,
receive
and
process,
because
I
think
receive
would
be
a
generated
by
the
SDK
when
the
application
calls
received
and
it's
the
processing
that
occurs
after
that
function,
returns
and
settlement
occurs
later
in
the
case
of
deliver.
E
It's
not
uncommon
for
the
Callback
like
when
the
to
do
the
processing
of
the
message
and
and
often
a
concept
known
as
sort
of
Auto
acknowledgment
is
used
where,
if
the
Callback
doesn't
throw
an
exception
that
results
in
settling
the
delivery,
and
so
you
kind
of
deliver
in
many
cases
would
serve
as
a
could
serve
as
a
process
and
settlement.
But
it's
much
harder
to
do
with
receive
and
but
in
other
cases
for
delivery
you
don't
use
Auto
acknowledgment.
E
Maybe
you
have
an
asynchronous
callback
to
an
application
which
then
puts
things
on
a
work
queue
that
multiple
threads
read
from
and
so
the
active
the
Callback
returning
doesn't
mean
it
has
been
processed.
So
there's
different
use
cases,
but
in
some
cases
I
can
see
where
delivery
could
be
combined.
I
think
it's
harder
to
combine
receive
unless
you're
not
using
Auto
instrumentation.
E
C
I
I
agree,
I
think
when
we
think
about
the
liver,
we
basically
have
the
more
or
less
the
push
operation
here
then
we
would
say:
yeah,
I
think
in
many
or
most
cases
that
includes
processing
like
to
deliver
span,
because
it's
basically
this
the
duration
of
this
callback.
That
usually
involves
the
processing
of
the
message,
and
then
we
talked
about
like
the
auto
settlement
that
in
many
cases
goes
with
it.
C
I
mean
another
thing
that
I
I
I
I
wonder
here
about
those
scenarios
where
we
have
one
span
that
kind
of
a
model
several
different
operation,
I
wonder,
instead
of
putting
it
all
in
the
operation
name,
whether
those
could
also
be
events
on
the
span
that
they
say.
Okay,
we
have
this
deliver
span
and
then
there
can
be,
let's
say,
a
saddle
event
on
this
deliver
span
and
this
this
could
then
even
work
for
let's
say
batching
cases,
the
gift
that
you
say.
C
Okay,
you
have
like
several
like
messages
that
are
delivered
and
when
each
single
of
those
is
like
settled,
you
kind
of
have
an
event
on
the
span.
I
mean
the
same
similar.
It
would
work
for
like
process
that
you
just
have
events
on
the
span
that
denote
okay.
When
processing
a
message
is
finished,
I
mean
then
you
would
have
like
still.
C
You
would
still
need
to
to
decide
on
one
of
those
operation
names
and
it
will
probably
the
name
of
the
operation
that
basically
the
span
starts
out
with,
but
then
you
could
like
model
what's
happening
during
the
span
duration
by
with
with
events,
and
you
could
even
then
more
like
flexibly
kind
of
denote.
What
operation
actually
fails,
because
you
could
just
add
that
as
a
status
on
the
event,
I
mean
it's
in
some
ways.
A
more
complicated
solution.
Then
then,
what's
proposed
here,
yeah.
E
I
feel
like
this
stuff
is
complicated
enough
and
I'm
I
think
I'm
kind
of
on
board
with
you
guys
like
that
sort
of
try
to
stick
to
what
we
have
here
and
you
know
let's,
and
we
can
extend
it
later-
try
to
contain
how
far
we
go
with
this,
because
it's
a
big
problem,
space.
C
I,
that's
that's
also
my
thinking
so
I
would
say
that
yeah
we
start
out
with
the
the
people
starting
out
with
what
we
have
and
if,
if
there
is
Need
for
more
for
more
composite
names,
yeah
we're
not
blocking
that.
So
we
can
still
do
that
on
top
of
of
the
minimal
set
that
we
have
here.
C
C
Okay,
so
I
will
also
write
here
that
yeah
we
will
the
that
we
that
we
plan
to
start
out
with
a
minimal
set
and
then
add
additional,
evaluate,
adding
additional
operations,
as
required.
C
C
Here,
oh
again,
this
was
also
longer
discussion
with
a
Paolo
about,
and
we
already
discussed
it
in
the
in
the
group
about
a
producer
site
settlement,
but
it's
recorded
that
you
can
have
a
public
span
and
then
you
kind
of
either
get
an
egg
pack
for
the
public
span
which
in
certain
terminologies
you
would
call
okay,
you
settled
this
publish
operation
or
you
just
have
a
fire
and
forget,
publish
operation
and
you
don't
get
an
egg
pack.
C
So
there
is
no
settlement
for
this
publish
operation,
and
here
Apollo
asks
whether
this
should
have
a
set
of
span
then
for
but
there
should
be
a
settle
span
to
kind
of
signify.
This
acknowledgment
of
a
message
by
the
intermediary-
or
she
puts
it-
is
producer
site
settlement
yeah.
We
discussed
this
and
I
think
in
one
regard.
I
would
say
the
same
here.
That
is
just
the
additional
complexity
that
we
don't
want
to
tackle.
C
I
think
in
this,
in
this
version,
or
in
this
with
this
iteration
I,
also
honestly
see
this
more
as
something
on
the
transport
layer
that
is
basically
related
to
the
underlying
protocol.
C
So
for
those
acknowledgments,
you
will
probably
have
like
some
mqp
related
spans,
if,
if
that
is
if
that,
if
you
want
to
model
that
so
you
will
basically
have
spans
like
that,
there
are
like,
in
the
protocol
level
like
a
level
below
what
we,
what
V
model
here
so
I
I,
would
suggest.
Yeah
and
I.
Just
I
can
add
this
I
think
I
didn't.
D
Form
it
makes
sense
that
if
you
are
waiting
for
an
arc,
then
the
duration
of
the
public
span
should
end.
When
you
receive
the
app,
the
app
should
indicate
the
span
status.
So
if
you
get
an
arc,
then
the
span
is
okay,
and
if
you
get
acknowledgment
that
there
was
a
problem
or
we
don't
get
acknowledgment,
then
you
know
there
was
an
error
on
the
publish
and
if
you
send
it
as
far
and
forget-
and
you
don't
wait
for
acknowledgment,
then
the
speculation
should
be
showed
just
covering
the
sending
of
the
spin.
E
C
Yes,
that
also
makes
sense
to
me:
I
mean
we
have
I,
think
we
discussed
this
I
summarize
the
options
here
like
for
synchronous
settlement.
It's
exactly
like
Amir
said.
We
want
to
wait
until
this
act
is
received
and
also
for
a
synchronous
settlement.
Basically
doing
what
you
said
yeah,
we
should
wait,
even
if
the
operation
is
asynchronous,
that
this
published
spans
should
wait
for,
for
this
asynchronous
settlement.
C
I
think
that's
more
of
a
gray
area
because
then
it
kind
of
gets.
It
gets
a
bit
like
iffy
to
when
you
think
about
the
duration
of
this
band,
because
then
that
doesn't
really
model
like
a
single
operation
anymore,
because
when
you,
when
you,
when
you
make
your
published
call,
basically
you
return
immediately,
but
then
the
span
would
still
the
span
would
still
like.
Last
until
the
settlement
callback
is
called
I.
E
I
feel
like
that's:
okay,
because
the
ultimately
the
message
is
still
alive
and
there's
operation
still
being
performed
on
it.
It's
just
not
in
the
you
know,
calling
threads
context
anymore.
E
I
I
think
that
logically,
it's
part
of
the
publish
operation
and
I
think
that
it
shouldn't
end
until
it's
been
acknowledged.
That's
that's
the
way
I
would
see
it.
C
Okay,
I
will
I
will
add
this
like
as
an
additional
comment
now,
because
you
think
we
agreed
that
for
synchronous
settlement.
That
should
definitely
be
the
case
and
I
wouldn't
also
say
that
even
it
should
be
it
should
in.
It
can
also
be
the
case
even
for
asynchronous
settlement
that
you
keep
keep
the
span
going
and
I
mean
if
you,
if
you
want
to
go
a
different
route,
yeah
I,
think
you
can.
C
C
Yes,
I
think
there's
like
he
described
some
async
scent
in
the
GMS
specification
that
is
mentioned
there
and
there
I
think
you
get
some.
You
have
some
kind
of
callback
here
on
completion.
D
So
I
think
it's
consistent
with
the
rest
of
the
specification
right,
because
if
you
like
calling
an
HTTP
request,
then
you're
like
sending
the
request
and
then
you
might,
your
code
might
still
run.
But
then
you
will
only
understand
when
you
get
the
response
right,
like
the
callback
is
invoked
or
the
async
function
is
awaited.
C
As
you
mean
as
to
answer
that,
for
both
cases
that
we
just
keep
the
span
also
for
asynchronous
settlement,
pictures
keep
this
initial
span
going
until
the
Callback
is
called
or
the
async
function
ends.
You
know.
C
Yes,
I
I
I
think
so
too
I
mean
in
terms
of
like
the
when
I
think
about
the
application
code,
flowy
others
I
think
there's
a
slight
difference,
but
you
have
like
an
async
sand
that
maybe
just
their
kind
of
your
puts
your
context.
Your
your
thread
context
like
in
some
kind
of
thread,
pull
queue
and
and
revisits
whether
it's
done
so
that's
handled
by
kind
of
the
your
run
time
or
whether
you
have
like
just
a
completion
callback.
That
is
your
responsibility
to
listen
to
and
react
to.
E
C
Think
it's
not
it's
not
worth
going,
I!
Think
for
us
going
too
deep
into
that
and
over
specify
here,
I
think
we
can
leave
it
with
that
open
model
where
we
say:
okay,
you
have
you
have
a
public
span,
but
whether
there
is
kind
of
yeah,
some
subtle
operation
here
we
just
don't
specify
that
that
is
to
the
the
question
of
the
user.
I.
C
Think,
usually
we
say:
okay,
the
publish
pen
covers
the
whole
duration
and
also
the
the
status
of
this
publish
span
kind
of
models,
whether
to
message
for
successfully
published.
C
Oh
this
I
think
I
can
actually
solve
here.
Powder
was
confused
about
like
boxes
that-
and
that
was
the
last
example
I
had
here
with
the
auto
Vista
intermediary
integration
here
and
I
initially
had
the
others
kind
of
a
two
like
empty
boxes
in
here
denoting
like
different
spans.
That
is
published
like
pairing
two,
and
also
that
is
delivered
here.
C
Parents
too,
but
I
just
made
this
more
opaque
now
in
just
just
have
like
this
unspecified
connection
here
for
the
publish
into
the
response
to
the
intermediary
and
I
hope
that,
on
the
one
hand,
it
makes
things
more
vague,
but
I
hope
you
have
four
powerlord
makes
things
more
key
or
because
we
don't
specify
how
exactly
those
those
those
correlation
here
is
created
and
yeah.
C
But
the
point
here
of
this
of
this
of
this
diagram
is
that
you
are
still
waiting
even
when
you,
but
when
you
take
the
intermediary
out,
you
still
have
like
our
standard
links
here
that
you
can
always
rely
on.
But
in
addition
to
these
things,
you
can
easily
adjust
your
prop
intermediary,
instrumentation
and
then
kind
of
link
it
all
together.
C
That's
the
main
idea,
but
it's
anyway
under
like
future
possibilities,
so
yeah
main
intent,
is
to
show
that
you
can
just
prop
this
intermediary
in,
without
disrupting
any
of
the
any
of
the
any
of
the
things
required
by
the
conventions
in
this.
C
Pr
so
I
think
I
will
I,
will
ping
Paolo
here
and
and
resolve
that,
and
they
are
asked
whether
this
makes
things
hero
for
him.
C
Oh
here
he
he
she
suggests
traditional
qualification
clarification,
because
basically
we
say
here
that
in
batching
scenarios,
especially
with
very
large
patches,
there
are
use
cases
where
users
don't
want
to
have
like
a
context
for
every
single
message,
because
then
there
would
be
just
too
many
too
many
links
in
the
end
and
thus
like
you're
having
a
unique
context
per
message
is
recommended,
but
not
required
and
I.
C
Think
what
Luke
Miller
suggests
here
is
that
we
add
some
clarification
that
basically
instrumentations
should
create
a
context
per
message
by
default,
but
may
or
should
support
like
some
configuration
to
disable
that
so
basically
giving
a
bit
of
a
refinement
of
this
here,
because
here
here
it
just
says:
okay,
you,
we
recommend
having
this
context
per
message,
but
we
don't
require
it,
and
she
basically
said
that
that
we
should
like
specify
a
default
behavior
that
we
say
okay
by
default.
C
C
So
I
think
it's
kind
of
it.
It
gets
like
a
more.
C
I
think
it
makes
it
a
bit
clearer
that
that
that
creating
a
context
per
message
should
be
the
default
in
any
case
and
that
basically,
some
action
from
the
user
is
required,
and
then-
and
that
is
not-
that
it's
not
like
a
decision
of
the
instrumenter
but
that
it
that
it's
a
decision
of
the
user
kind
of
to
to
activate
or
deactivate
this
context
per
message.
C
Then
this
route-
you
already
gave
a
thumbs
up
here
so
I
will
I
will
change
accordingly,
and
here
that's
also.
C
Here
we
talk
about
Auto
settlement
in
poor
scenarios
and
basically,
in
that
regard,
we
we
I
think
we've
learning
in
there
that
we
also
want
to
have
a
set
in
Spain
for
auto
settlement
that
we
have
that
separately.
C
Modeled
and
the
current
model
here
or
the
recommendation
here
is
that
yeah
there
is
some
kind
of
ambient
span
that
covers
both
the
deliver
and
the
saddle,
operation
and
Bartlett
Miller
suggests
here
that
the
saddle
span
should
be
a
child
of
the
deliver
span
in
terms
of
when
it
comes
to
comes
to
to
Auto
instrumentation
in
particular.
C
E
Yeah
I
mean
the
model
that
I
think
makes.
The
most
sense
is
to
have
only
a
deliver
span,
because
I,
don't
I,
think
that's
what
people
are
going
to
mostly
want
to
measure
is
the
processing
time
during
the
deliver
callback
and
measuring
the
time
that
the
back
end
takes
to
to
handle
the
settlement
is
not
normally
going
to
be
of
much
interest
and
it
would
be
costly
to
add
this
extra
span
like
in
terms
of
extra
it's
extra
noise
and
data
in
the
back
end.
E
So
as
long
as
it's
optional
I,
don't
the
structure
I'm
not
too
opinionated
about
for
when
we
do
include
I,
would
think
for
the
stuff
I'd
be
interested
in
implementing
I,
probably
wouldn't
Implement
a
settle
span
at
all.
So
as
long
as
that's
an
option
I'm
not
as
concerned
with
the
structure
for
the
settlement,
I.
C
E
He
yes,
although
I
I
I,
don't
want
to
get
into
too
many
details
in
in
our
messaging
system.
The
Southwest
messenger
system,
the
the
acknowledgment
is,
is
sort
of
a
and
like
it
doesn't
it's
not
really
a
defined
end
time.
It's
a
little
bit
complicated.
It's
like
there's,
not
a
three-way
handshake
on
the
acknowledgment,
but
there
are
mechanisms
through
these
of
IDs
that
prevent
redelivery
of
messages,
but
I
won't
get
into
all
of
the
details.
That's
why,
for
our
case,
I
wouldn't
want
to
be.
You
know
obligated
to
create
a
settlement.
D
I
think
that
whatever
Spencer
generated,
they
should
follow
how
the
code
looks
like.
So
if
the
user
is
explicitly
calling
a
certain
a
function
like
doing
an
operation
to
certainly
spend,
then
I
think
it
should
be
recorded
or
we
should
recommend
for
it
to
be
recorded
and
I'm,
not
I.
Don't
think
we
should
specify
that
the
parent
is
the
is
the
level
span
or
some
other
Spanish
just
should
be
the
ambient
spending
at
the
time
of
calling
the
setup,
but
I
do
support
adding
a
link.
C
Yes,
let's
see
whether
I
think
we
already
after
that
regarding
the
settlements,
let
me
see.
C
Maybe
definitely
have
to
settle
span.
We
said
my
link
to
the
create
or
published
span
of
the
messages
foreign,
but
we
don't
require
a
link
to
the
deliver
or
we
don't
even
mention
links
to
the
deliver
or
receive
spans.
D
We
just
need
to
specify
that
it
may
record
the
link
and,
for
example,
if
it's
always
the
child
of
the
deliver,
then
maybe
the
link
is
not
so
valuable
but,
for
example,
in
a
specto
we
read
the
messages
from
sqs
and
we
batch
them
into
large
batches
and
only
process
them
later
like
not
not
as
we
receive
them
and
then,
when
we
settle
them,
it's
like
a
completely
different
Trace
than
the
trace
that
received
them
and
I
wouldn't
want
to
see
this
settled
operation
being
disconnected
from
where
it
actually
happened
and
moved
to
some
other
place.
C
Yes,
I
think
we
only
have
two
minutes
left
and
the
athlete
Mill
is
not
here
today.
I
would
actually
like
to
I
will
not
close
this
command,
but
maybe
we'll
start.
We
will
continue
discussing
this
next
time,
because
I
also
I,
remember
that
Luke
Miller
kind
of
see
she
she
wanted
or
she
was
arguing
for
like
having
stronger
requirements
on
the
saddle
spans,
and
there
were
actually
very
few
diverting
that
the
Saddles
Shadow
settle,
span
or
event
should
be
created
for
every
settlement
operation
regardless
of
manually
or
automatically
and
I
mean.
C
That
is
a
bit
at
odds
with
what
what
to
answer
before,
but
he
said,
okay
yeah.
Actually
it's
not
that
interesting
in
many
cases,
so
maybe
we
can.
We
can
then
discuss
together
with
Luke
Miller
next
time
how
to
proceed
here.
C
Also,
then,
going
into
what
Amir
said
today
of
having
like
the
links
here,
I
mean
one
one
thing
we
have
here
that
and
I
think
that
is
for
the
case
where
people
don't
tend
to
want
to
have
too
many
spans
that
this
saddle
operation
can
also
be
an
event,
maybe
on
the
deliver
span.
So
that's
an
that's.
That's
that's
a
way
to
kind
of
reduce
the
count
of
spans
and
you
just
have
a
span
event
that
you
can
ignore.
C
If
you
are,
if
you
are
not
interested
in
it,
but
the
I
think
the
point
that
Luke,
Miller
and
and
I
remember
that
Miller
was
arguing
for
that.
The
tomatoes
that
are
you
should
have
this
settlement
operation
model,
somehow
either
spans
or
events
and
through
this
I
mean
shoot.
Basically,
is
the
strongest
the
strongest
directive
views
here?
We
don't
use,
we
don't
use
a
must.
I
mean
assuming
you
use
must
not
here,
but
basically
should
that
shoot.
C
That
puts
the
saddle
operation
on
par
with
like
creating
a
receive
or
the
device
bands
and
yeah.
Maybe
we
should
continue
discussing
next
time
and
also
then
talk
about
to
ends
Viewpoint,
where
I
said,
okay
is
not
interested
or
users
are
probably
not
interested
in
setting
spans
in
many
cases,
and
it's
just
overhead.
E
I
think
events
are
sufficient.
I
would
just
wonder
about
Auto
ack,
where
applications
don't
explicitly
acknowledge
anything,
then
it
probably
makes
sense
to
not
have
an
event,
but
that
can
be
accomplished
with
this
anyway,
so
I
think
allowing
it
to
be
an
event
on
another
span.
It
addresses
my
concern.
C
Okay,
that
sounds
good,
but
then,
let's
maybe
stop
here
and
revisit
it
next
time,
together
with
Luke,
Miller
and
I,
will
write
comments
or
make
changes.
According
to
all
the
previous
comments
that
we
talked
about
and
there's
still
some
left
from
look
below
here
so
but
those
are
also
maybe
ideally
then
next
sessions
she
can
join
and
we
can.
C
We
can
go
through
that
so
and
also
you,
when
you
have
some
time,
please
go
over
the
pr
see,
see
whether
there's
anything
that
any
feedback
that
you
have
because
I
think
as
soon
as
we
have
this
allowing
links
adding
links
on
spans
after
span
creation.
C
As
soon
as
we
have
this
through,
which
hopefully
happens
it
happens
soon,
then
I
think
we
can
try
to
to
put
this
outtap
like
ready
in
our
state
status,
ready
for
video,
putting
it
out
of
the
draft
status
and
yeah
try
to
push
that
further.
A
A
C
Yes,
definitely
I
mean
I,
I
would
actually
Carlos
is
I,
think
working
on
the
pr.
So
he
will
open
the
pr
and.
C
I
would
actually
wait
a
bit
to
see
if
maybe
other
people
that
are
not
affiliate
with
our
group
come
up
with
some
concerns.
First,
maybe
that
that's
the
case
and
if,
if
other
people
come
up
with
our
conference
first,
that
I
think
we'll
actually
be
good
to
make
a
stronger
point.
But
if
not
definitely
we
should
add
this
to
the
pr
bonds.
So
once
it
is
open.
C
Are
meeting
this
Monday
it's
on
the
calendar,
so
Monday
8
A.M?
If
you
have
time
and
I'm
not
sure
whether
Carlos
manages
to
open
the
pr
before
Monday,
if,
if
so,
we
could
discuss,
discuss
it,
Monday
and
otherwise.
I
think
here
next
big
Source
day
will
be,
will
be
a
good
time
to
talk
about
that.
If
the
pr
is
open
until
then,.
C
Okay,
awesome.
Thank
you.
Everybody.
Thank
you
so
productive
session
and
see
you
next
week,
either
Monday
or
Thursday.