►
From YouTube: 2022-03-24 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).
C
So
the
last
time
I
said
a
little
ping
boggton
and
maybe
that
we
can
continue
discussion
with
him.
I
think
him
yesterday
he
responded
and
he
said
he
thinks
he
can
come
so,
let's
see
otherwise
I
will
ping
him
for
next
weeks.
Then
we
still
have
lots
of
other
stuff
to
discuss
but
yeah.
If
bogdan
manages
to
come,
we
will.
C
C
C
Agenda
so
yeah,
please,
please
add
your
name
here,
so
the
first
point
was
with.
If
brockton
would
have
come,
we
would
have
continued
our
discussions
regarding
links
because
we
for
this
one
scenario:
we
need
links
to
be
created
after
spain,
creation
and
bogdon
kind
of
is
a
bit
pushing
back
on
that.
So
last
time
we
started
kind
of
going
through
our
scenarios
with
him
trying
to
explain
him
and
he
put
kind
of
basically
put
us
a
bit
in
question
on
that
which
is
good
but
yeah.
C
We
didn't
reach
any
conclusion,
so
we
will
continue
that
with
him
once
he
once
he
manages
to
join
and
looking
on
the
overall
gender,
the
context
propagation.
That
is
basically
done.
This
transport
layer
details
we
postponed
to
post
v1
producer
instrumentation.
I
put
a
done
here
because
we
have
something
in
the
dock.
Also
for
those
who
haven't
seen
it.
I
added
some
examples
to
the
dock.
C
The
example
should
cover
most
of
the
or
actually
should
cover
all
of
the
scenarios
that
we
considered
on
producer
and
consumer
side.
So
if
you
have
some
time,
maybe
just
look
through
that
and
see
if
everything
makes
sense
to
you
or
something
is
missing.
C
As
I
said,
the
additive
examples,
because
here
we
just
have
a
horse
of
text
which
is
often
hard,
might
be
hard
for
many
people
to
go
through.
So
here
you,
it
might
be
easier
to
just
look
at
examples
and
then
decide
whether
things
make
sense
or
not
so
yeah
the
push
scenarios
we
have
done
too.
I
mean
that
was
one
of
the
nice
things.
C
Last
time
we
stopped
done
that
we
went
through
all
those
scenarios
here
and
everything
kind
of
made
sense
to
him
or
the
push-based
scenario
here
just
here
this,
the
last
one
like
the
based
one
that
might
need
more
discussion
and
that
sort
of
one
where
we
would
like
to
need
to
spend
creation
the
the
link
but
adding
links
after
spank
creation,
so
but
all
the
other
scenarios
before
and
also
the
way
how
we
use
links,
tear
there
that
seemed
fine
to
walk
down.
So
I
put
this
on
done
and
here
the
only
one.
C
The
only
thing
in
progress
are
the
four
scenarios
that
basically
spending
the
talks
with
stockton
and
then
what
we've
left
here
is
process,
bands
and
settlement,
and
I
think
I
would
really-
or
since
we
have
ludmilla
today-
love
to
start
talking
about
settlement,
because
the
meal
already
has
some
experience
on
every
event
upside
with
settlement
instrumentation,
and
maybe
we
can
get
some
some
first
idea
on
that
and
the
other
in
the
further
future.
C
D
Pretty
quick
question,
but
just
do
we
want
a
project
board
to
track
our
process.
This
is
something
I'm
recommending
to
all
the
different
spec
subgroups
right
now.
If
we
want
one
I
can.
I
can
make
one
and
I
believe
we
have
enough
people
here
who
are
community
members,
so
we'd
be
able
to
organize
everything
into
a
spec
issue,
basically
and
then
put
it
in
this
project
board.
So
there's
an
easy
way
for
people
to
see
what
are
what
our
progress
looks
like.
C
Well,
I'd
really
appreciate
that,
because,
basically
now
this
here
is
our
project
board.
What
we
just
went
over,
so
we
can
yeah
so.
C
We
had
the
two
different
settlement
scenarios.
The
one
was
that
that's
basically,
my
first
outta,
the
one
was
individual
settlement
where
each
message
needs
to
be
settled
individually
and
the
other.
The
other
settlement
scenario
was
checkpoint
based
settlement.
So
basically
a
checkpoint
set
a
base
settlement.
A
checkpoint
is
based
at
a
certain
point
in
a
message
stream
and
everything
before
the
point
is
considered
settled
and
everything
after
this
checkpoint
is
considered
not
settled,
and
I
think
when
talking
about
when
I
thought
a
bit
about
settlement
instrumentation.
C
Basically
those
two
scenarios
are
really
helpful
because
just
how
it
seems
to
me
it
seems
to
me
here
in
this
first
scenario.
Each
settlement
operation
can
be
correlated
to
some
message,
and
probably
we
want
to
see
this
correlation
in
a
trace.
C
In
the
second
scenario,
setting
a
checkpoint,
it's
pretty
hard
and
maybe,
in
some
cases,
impossible
to
correlate
these
two
messages
that
are
settled
by
this
operation
and
I'm
not
sure
if
we
can
require
or
ask
for
capturing
this
in
a
trace,
and
there
will.
B
Yeah,
it's
a
great
point
so,
like
imagine
some
scenarios,
so
let's,
let's
talk
about
maybe
individual
settlement
first,
and
in
this
case,
what
the
ideal
situation
is
that
the
processing
span
it's
a
parent
of
a
settlement
right
because
you
cannot
say
the
processing
is
successful.
Unless
you
until
you
settle
right
and
if
settlement
fails,
then
you
would
have
to
reprocess
it
again
anyway
right
so,
ideally,
the
settlement
span
is
a
child
of
processing.
B
If
you
write
the
code
in
a
different
way
right,
if
you're
processing
ends
before
settlement,
then
you
probably
doesn't
write
this
code
correctly
anyway
right
we
can
talk
about
how
we
can
give
people
an
idea
that
they've
done
it
right
or
that
they
can
see,
maybe
if
they
can
correlate
still.
But
basically
the
rule
of
thumb
settlement
is
the
last
thing
you
do
during
processing
and
then
naturally
it
happens
as
a
child.
B
The
same
is
true
for
checkpointing.
Actually,
if
we
have
oh
sorry
for
the
offset
based
checkpointing,
so
if
we
have
a
processing
span
that
describes
all
of
the
messages
that
were
received
in
the
badge
right
when
we
settle,
this
is
the
last
thing
we
do
and
we
don't
say
which
messages
we
thought.
Oh,
but
it
should
be
probably
the
child
of
this
overall
protestant
thing.
B
There
is
no
way,
as
you
mentioned,
to
correlate
right.
So
I
think
the
good
step
here
would
be-
maybe
for
me,
but
by
the
next
time,
to
write
some
code
examples
and
demonstrate
what
they
just
thought
and
show
some
traces,
and
then
we
can
talk
in
more
details
about
it.
What
do
you
think.
C
Yes,
that
definitely
sounds
good.
I
mean
one
thing:
you're
brought
up
is
also
interesting.
You
brought
up
the
processing
span
and
that's
also
actually
still
on
our
list
to
be
discussed,
and
I
mean
for
me
for
me
for
settlement.
One
question
is
also
to
ask:
I
mean
the
the
produced
foundation,
that's
something
we
definitely
that
that's
more
or
less
required,
because
without
that
you
don't
have
any
kind
of
great
context.
Also
this
push
and
pulls
in
our
instrumentation,
depending
on
what
you
have
like
this
liver
receive
spin.
C
It's
also
required
more
or
less
to
create
the
the
to
link
the
producer
and
the
consumer
traces
together
for
processing.
We
said:
okay,
we
cannot
require
processing
spends
in
our
cases,
because
there
are
cases
where
there
is
no
processing
and
we
work
with
on
the
edge
to
give
like
a
guidance
for
for
processing
expense
at
all
in
this,
in
in
our
semantic
conventions
and
also
for
settlement.
I
wonder
if
that
is
something
that
we
can
require
as
strong
as
you
require.
C
C
So
so
I
wonder
if
settlement
there
is
the
same,
basically
in
on
the
same
level
as
the
process,
bands
which
are
kind
of
nice
to
have
but
not
required
or
if
settlement
will
be
on
the
same
level
as
this
producer
instrumentation
or
push
and
pull
instrumentation.
That
is
kind
of
more
or
less
required.
B
I
I
think
the
our
concern
was
processing.
Is
it's
not
feasible,
but
for
settlement
it
is
right.
We
can
either
create
a
link
because
we
know
what's
being
settled.
If
it's
a
single
message
right
or
we
can
write
an
offset
as
an
attribute.
If
it's
the
checkpoint
based
agreement,
then
we
can
do
it
and
it's
it's
an
essential
part.
If
it
happens
at
all,
it
feels
it
must
be
instrumental.
C
A
A
Okay,
so
I
will
show
my
screen
just
a
second:
you
have
to
stop
shell.
I
think.
A
Yes,
I
can
see
it
yeah,
so
what
I
did
is
I
looked
at
some
examples
from
node,
sqs,
aws,
sqs,
rabbit,
mq
and
kafka,
and
I
like
summarized
how
the
settlement
works
in
each
one
of
them
and
I
also
wrote
a
few
categories
for
them.
So
my
research
is
this,
so
I
have
a
few
categories.
One
is
the
settlement
type.
A
So
one
option
is
like
there's
no
settlement
at
all
in
rabbitmq
you
can
configure
the
consumer
for
nowhere,
no
arc,
it's
called
no
arc
and
then
like
the
rabbitmq
server,
just
sends
the
message
and
he
doesn't
accept,
expect
any
feedback
back.
So
this
is
a
one
option
and
no
settlement.
I.
A
Yeah
yeah:
this
is
a
file
and
foga,
and
the
second
option
is
the
auto
settlement
with
auto
settlement
like
the
user.
It
doesn't
have
to
do
anything
specifically
to
settle
the
message
like
the
callback
is
being
invoked
and
if
it
finishes
with
no
exception,
then
the
sdk
automatically
settles
the
message
and
if
an
exception
is
thrown,
then
the
message
is
not
settled,
but
the
user
doesn't
have
to
do
anything
on
his
side
like
it's
just
invoking
some
callback
and
that's
it.
A
So
this
is
the
auto
settlement
and
then
we
have
a
per
message
settlement
and
this
is
divided
into
two,
so
some
of
the
apis.
They
support
like
a
certainly
settlement
of
a
single
message
and
some
support
a
settlement
of
a
batch
of
messages
at
one
time,
for
example,
sqs
supports
this.
You
can
give
it
like
an
array
of
messages
and
ask
it
to
settle
all
of
them
at
once,
and
the
fourth
settlement
type
is
the
checkpoint
settlement
which
we
talked
about.
A
So
the
next
category
is
the
initiator
of
the
settlement,
so
like
some
sdks,
they
they
need
the
user
to
settle
the
messages
and
some
sdks
they
like.
This
is
the
auto
settlement,
the
option
where
they
they
have
some
logic
to
do
it
automatically
for
the
user,
so
it
doesn't
have
to
call
any
api
to
to
settle
and
the
fourth
category
is
a
success
indication.
I
called
it
it's
like
some
messaging
systems.
A
They
support
only
success
like
you
have
to
tell
it
that
the
message
is
successful
and
you
can
delete
it
but,
for
example,
in
rabbit
you
can
settle.
The
message
has
failed.
You
can
like
tell
a
rabbit
mq
that
the
message
was
not
processed
and
it
needs
to
be
rescheduled
to
another
consumer.
A
So
this
is
another
category
and
the
last
one
is
the
sdk
type.
So
some
sdk
is
there
like
a
like
an
lpc.
You
just
call
if
you
tell
it
delete
message
or
ack
message,
and
it
does
nothing
except
translating
it
to
the
wire
protocol
and
sending
it
to
the
server,
but
some
sdks,
for
example,
a
kafka
they're
a
stateful,
so
you
settle
messages
and
the
kafka
has
a
state
that
the
kafka
client
has
a
state
and
it's
a
tracking
which
message
are
settled
and
once
every
some
time
or
after
enough
messages
are
settled.
A
It
like
send
a
message
to
the
to
the
kafka,
vocal
and
then
moves
the
checkpoint.
So
these
are
the
categories
that
I
identified
and
I
really
want
to
talk
quick
about
like
a
few
examples.
So,
for
example,
in
sqs
there
are
two
ways
to
settle
a
message,
delete
message
and
delete
message
batch.
A
So
in
sqs
you
settle
a
message
like
a
term
message
you
can.
You
can
only
like
settle
one
message.
Each
message
is
in
individual.
You
can
settle
it
by
itself
and
you
can
do
it
in
a
batch
and
the
user
have
to
do
it,
and
you
can
only
settle
a
message
with
success.
You
can't
tell
back
to
sqs
that
you
failed
processing
it
and
it's
basically
like
an
opc.
A
A
You
can
call
ark
on
a
single
message
or
where,
like
there
is
an
option,
it's
called
all
up
to
like
you,
give
it
a
message,
and
it
settles
settles
all
the
messages
until
this
message
and
then
you
have
alcohol
which
settles
all
the
messages
on
the
channel
and
then
you
have
the
negative
luck,
so
there
is
knock
and
knock
all
and
also
reject.
A
So
it's
there's
a
lot
of
way
to
settle
and
you
can
also
when
you
settle
a
message
you
can
tell
it
all
up
to
which
I
talked
about
it.
Like
you
give
it
a
message.
It
settles
everything
until
this
point
and
you
can
give
it
a
parameter.
I
call
the
re-key
where
you
can,
if,
if
you
failed-
and
you
don't
want
it
to
be
rescheduled
because
you
know
the
message
is
not
possessable,
then
you
set
it
to
false.
But
if
there
was,
I
don't
know
something
a
connectivity
issue.
A
You
can
tell
it
rick
you
too,
and
then
it
will
send
it
to
another
consumer
later
yeah,
so
the
type.
So
you
can
the
type
no
settlement
or
message
settlement
or
checkpoint
message
settlement.
If
you
give
it
they're
all
up
to
the
user,
have
to
do
it,
like
you
have
to
call
the
the
settlement
on
each
message
from
the
userland.
A
So
kafka
is,
as
I
said
before,
it's
a
stateful.
So
you
settle
a
single
message,
but
but
kafka
works
with
a
checkpoint,
so
the
kafka
client
at
least
you
know
they
don't
didn't
examine
it
in
other
languages,
but
it
it
has
a
state.
It's
like
keep
track
of
each
message.
If
it's
settled
or
not,
and
you
can
configure,
you
can
tell
it
like
every
five
second
commit
the
checkpoint
back
to
the
kafka
server
or
once
a
thousand
messages
has
been
settled
committed
to
the
server.
A
So
it's
more
interesting,
there
is
the
state
and
you
can,
of
course,
only
settle
a
message
with
success
because
it's
a
checkpoint,
you
can't
like
have
holes
in
the
in
the
in
the
kelso
and
yeah.
So
so
these
are
the
examples.
Any
questions
about
it
or
something.
C
I
have
a
question
regarding
this
initiator.
You
have
either
it's
the
user
or
it's
the
sdk
who
initiates
and
when
the
sdk
initiates
in
those
examples
studio
gave
like
the
auto
settlement
is:
when
is
the
settlement
initiated
there?
Is
it
initiated
before
processing
like
up?
Is
it
initiated
before
the
messages
are
passed
to
the
user,
or
is
it
initiated
at
some
kind
of
timer
based
camera
based?
A
It's
like
internal
process,
message
queues
and
then
so.
So
what
like
the
process
is
that
you,
the
sdk
it
receives
the
message.
It
initiates
the
callback
and
then
it
waits
until
this
callback
terminates
and
if
this
callback
like
if
the
function
the
callback
function,
ends
with
a
success,
then
it
settles
the
message
and
if
it's
a
frozen
exception,
then
it's
not
settled
the
message
or
informed
and
walk
out
of
it.
Oh.
C
I
see
I
get
it
now,
so
it's
basically
it's
it's
bound
to
the
success
or
to
the
return
code
of
this
callback.
A
Okay,
yeah
yeah,
so
so
regarding.
I
think
we
have
to
agree
on
a
few
questions
like
the
first
one
is:
what
do
we
want
to
use
to
the
settlement
instrumentation
to
represent
like
do
we
want
it
to
to
follow
the
the
api
like
if
the
sdk
exposes
an
api
for
settlement?
Do
we
want
to
create
a
span
when
the
user
invokes
this
api,
or
do
we
want
to
instrument
the
lower
level
transport
between
the
the
client
and
the
broker?
A
B
Thank
you.
I
have
a
couple
of
comments
on
this
regarding
the
api
versus
transport.
I
think
here
we're
talking
about
the
api.
Transport
can
be
http.
It
can
be
anything
it's
out
of
our
control
right
eventually,
maybe
we
will
instrument
the
mqp
and
the
ribbit
version
of
it,
and
maybe
kafka
will
instrument
the
transport
we
don't
care.
It
just
happens
within
this
call.
It's
nested
spans,
so
I
think
it's.
This
version
we're
talking
about
logical
operations
rather
than
physical
ones,
with
right.
C
A
I
I
just
want
to
say
that
I
also
agree,
but
I
just
want
wanted
to
make
sure
that
we
can
all
agree
on
that
and
it.
What
it
means
is
that
we
don't
create
a
spend
for
this
no
settlement
and
auto
settlement,
because
there's
no
way
user
calling
some
api
involved
in
the
process.
A
E
A
B
So
no
settlement
is,
I
agree
with
you,
but
all
the
settlements.
So
for
us
for
that's
the
case
right,
how
does
it
look
for
us?
We
have
a
api
methods
that
receive.
We
have
an
api
method
that
settles
and
we
have
maybe
in
a
different
package.
B
B
I
can't
tell
you
who
it
I
will
have
to
refactor
my
sdk
a
lot
in
order
to
change
this
right
and
also
like,
if
I'm
a
user
and
I
do
auto
settlement,
imagine
I
thought
I
do
of
all
the
settlement,
but
in
fact
I
did
none.
I
want
to
know
about
it
right.
A
Yeah
yeah,
I
agree
what
I
imagine,
but
there
could
be
other
options
as
well.
Is
that
the
sense
the
auto
settlement
is
bound
to
the
invocation
of
the
callback
and
the
sdk
awaits
the
the
the
callback
to
finish
and
looks
at
the
result
and
then
execute
some
settlement,
so
I
want
to
suggest
to
add
an
attribute
to
the
deliver
span
to
to
give
like
the
settlement
result
based
on
the
success
of
the
callback.
I
hope
I
was
clear
enough.
B
A
B
C
C
I
think
that's
not
something
that
we
should
prevent
or
kind
of
forbid.
I
mean,
I
think,
that's
fine,
I
think
we're
not
gonna
require
it,
and
it
might
be
just
enough
to
have
this
attribute
on
the
delivery
span.
But
if
the
sdk
creates
this
stand
for
auto
settlement,
I
I
think
there
is
no
not
much
harm
in
that,
at
least
from
my
point
of
view,.
A
I
agree
with
you.
The
thing
that
makes
most
sense
to
me
is
to
follow
like
the
the
api
calls
on
the
on
the
messaging
sdk
so
like
I
imagine
that
only
when
the
user
invokes
some
function
to
settlement
to
do
the
settlement,
then
we
create
a
spam
for
that.
But
but
if
it's
happening
internally,
then
we
should
just
decorate
the
delivery
spend,
but
I'm
not
against
adding
the
settlement
for
the
other
option
as
well.
If
it
makes
sense
to
to
you.
B
A
How
come
we
don't
know?
Because
we
we
can
we
patched
the
settlement
function
right
so
you're
saying
maybe
it's
something
internal
and
within
the
sdk
that
invoke
the
function.
I
see
what
you
mean:
yeah,
okay,.
C
F
I
was
just
wondering
yes,
I
was
just
wondering
so
if
if
in
this
case,
for
example,
this
case
of
the
the
automatic
set
settlement,
for
example,
if
my
function
ends
normally,
then
the
sdk
will
create.
This
will
invoke
this
auto
settlement
on
its
own.
F
But
at
that
point
we
will
have
an
active
span
right.
The
parent
span
will
be
active,
I
guess
couldn't
the
sdk
create
another
span
and
it
would
be
already
automatically
the
child
of
that
one
or
or
not.
Wouldn't
that
work,
because
does
it
matter
that
who
called
right?
But
if
it's
in
the
same
context,
wouldn't
that
work
that,
if
I
create
a
new
span,
would
be
in
the
same
context
of
the
parent
right
or
not
really.
A
It
depends
on
the
instrumentation,
but
I
think
it's
not
necessary
because
in
this
situation
you
can
like
have
an
attribute
saying
that
the
message
was
auto
settled
and
you
look
at
the
span
status
code
and
if
it's
an
error,
you
know
that
it
failed.
And
if
it's
success,
you
know
that
it
was.
F
Then
you,
you
settle
the
whole
batch
or
how
do
you
say
that
two
messages
were
settled
and
one
failed,
and
then
we
can't
right
this
way
with
an
attribute.
A
Yeah,
so
so
it
depends
on.
Like
the
the
case.
We
have
to
examine
a
case
like
this
and
maybe
for
next
week.
I
can
prepare
a
few
examples,
but
my
understanding-
and
that
could
be
wrong-
is
that
when
you
do
a
lot
of
settlement,
it's
always
a
for
single
message.
So.
A
B
No,
the
same
thing
that
we
either
if
we
create
a
settlement,
spend
yes,
it
will
be
a
child.
If
we
don't
create
it,
it
can
be
an
attribute
or
it
could
be
spam
status
yeah.
If
it's
a
badge,
then
it
depends
right,
but
it
still
can
be
a
child
of
this
callback.
F
Okay,
I
just
wanted
to
okay,
because
I
because,
if
it's
something
that
we
want
to
have
like
the
settlement
is
important,
then
I
feel
that
we
can't
enforce
or
we
can't
we
can't
do
it
like
in
an
automatic
way.
Let's
say
like
that,
but
I
feel
that
we
still
need
to
just
leave
it
like
open,
do
whatever
you
want.
F
I
think
we
should
probably
give
like
give
directions
if,
for
example,
I
want
to
put
in
my
sdk
for
this
auto
settlement,
I
want
to
create
always
this
pen,
for
example,
that
I
think
we
should
have
in
our
conventions
how
like
how
to
name
it,
what
to
put
inside
and
so
on
when
to
create
it,
and
things
like
this
right.
B
Yeah,
and
also
like
imagine
if
there
is
a
settlement,
call
imagine
even
if
it's
auto
settlement
and
within
it
there
will
be
transport
calls,
there
will
be
logs,
there
will
be,
maybe
a
retries,
maybe
something
else
we
would
want
to
have
spent
for
it
regardless.
It
feels
to
me.
B
C
I
mean
to
me
it's
just
a
matter
of
kind
of
providing
the
different
like
guidance
or
conventions
for
the
different
puzzle
pieces.
So
we
basically
say:
okay,
that's
the
individual
settlement,
there's
trackboard
spin
settlement.
That's
the
span!
That's
the
name
of
this
band.
Those
are
the
attributes
and
then
how
the
users
use
those
bands
we
can
that
we
can
leave
that
basically
open,
because
even
with
the
auto
settlement,
the
minute
some
it's
either
individual
settlement
or
checkpoint
settlement,
and
we
kind
of
specify
those
two
cases
so
even
for
autos,
auto
settlement
like
the
sdks.
C
If
they
want
to
create
spams
or
if
they
create
spams
anyway,
then
they
just
kind
of
take
these
pieces
and
put
them
somewhere
that
fits,
but
we
don't
need
to
strictly
specify
where
they
have
where
they
have
to
put
them
right.
C
The
use
cases
will
be
pretty
different
and
then
we
still
have
okay,
we
have
the
conventions
of
the
naming
of
the
spans.
We
have
the
attributes,
but
how
they
kind
of
appear,
then,
in
the
trace.
The
settlement
spans
at
least
for
other
settlement
that
is
then
up
to
the
sdks
or
for
the
users.
B
B
I'm
100
sure
you
have
to
use
another
thing
to
settle
and
another
thing
is
actually
blob
storage,
and
so
you
have
different
configuration
for
your
messaging
and
for
your
storage
and
you
use
different
end
point
use
different
everything.
You
can
misconfigure
your
settlement
and
then
you
will
end
up
in
a
situation
that
okay,
everything
has
failed
to
settle,
but
you
don't
know
why,
and
why
is
because
the
the
call
the
internal
call
is
failed.
B
So
unless
we
definitively
say
that
if
you
settle
create
a
spa,
if,
if
this
settlement
is
not
local
okay,
I
think
this
is
important
distinction.
If
your
settlement
is
local,
it's
an
immediate
and
it's
always
successful.
Then
okay
go
for
it
don't
create
a
span.
But
if
your
settlement
is
involved
involves
something
else,
the
remote
service,
then
it
has
to
be
a
spam.
B
F
Does
the
sdk
that
you
know
today
for
for
this
case
that
that
contacts
contacts
azure
they
will
storage?
Does
it
already
create
a
spend
today
for
this,
for
this
operation
or
or
no
yep.
C
Okay,
so
so
I
think
the
main
basically,
the
main
dispute
here
is
about
whether
we
should
have
like
two
ways
to
signify
settlement
and
where
one
would
be
a
separate
span
and
the
second
one
would
be
an
attribute
on
a
maybe
deliver
span
or
if
we
just
want
to
require
like
a
span
for
a
settlement.
Operation,
regardless
is,
is
that
do
I
understand
that
correctly
miller.
G
It
would
make
sense
in
that,
if
that's
the
pattern
to
have
one
span
for
all
of
that,
maybe
an
event
in
that
span
when
processing
return,
finished
and-
and
you
know
what
the
result
of
processing
was
and
that
the
status
of
the
span
indicates
the
complete
entire
operation.
But
if
it's
not
a
sequence
like
that,
and
it's
broken
up
into
separate
operations,
that's
when
you
know
having
an
extra
span
would
be
more
valuable
and
if
spans
are
expensive
and
a
common
pattern
doesn't
really
get
a
lot
of
value
out
of
an
extra
span.
B
Imagine,
for
example,
if
we
have
this
processing
span
right
and
there
are
some
user
calls.
I
don't
know,
maybe
they
call
some
database
or
something
right,
and
so
there
is.
There
are
a
bunch
of
nested
spans
under
processing
which
are
user
related
and
then
at
the
end
you
see
a
bunch
of
transport
things
right.
Maybe
there
are
retries.
Maybe
there
are
multiple
requests
to
do
something
multiple
calls
and
you
you
have
no
way
of
knowing
your
quad
didn't.
Do
it
at
all.
You
don't
know
what
happened
right.
G
B
So
you
get
the
call
back
and
then
from
your
you
from
the
code,
you
you
just
return
right
and
then
you
go
and
check
your
traces,
and
now
you
see
this
bunch
of
things
at
the
end,
or
maybe
some
logs
that
you
can't
understand
where
the
what
they
are
related
to
right,
whether
did
they
happen
during
processing.
Did
they
happen
during
settlement?
B
If
your
transport
call
failed
at
the
end,
maybe
you
can
figure
it
out,
but
maybe
you
misconfigured
your
settlement
thing
right,
so
it
it
feels
like
this
is
the
way
of
grouping
whatever
happens
internally
or
imagine.
My
processing
took
one
millisecond
and
settlement
took,
I
don't
know,
20
seconds.
B
I
want
to
know
that
was
this.
This
was
time
spent
in
settlement,
not
in
my
processing
right.
G
B
When
you
talk
event,
who
do
you
think
will
create
it?
I'm
not
sure
I
understand
this
part
well.
G
In
the
case
of
of
the
auto
settlement
right
where
you're
calling
a
callback,
my
my
what
I'm
envisioning
is
that,
when
the
callback
returns
that
the
sdk
adds
an
event
to
that
span
at
the
time
the
callback
returned
and
then
would
end
the
span
when
the
outcome
of
the
settlement
was
complete.
B
But
then
I
my
understanding
was
okay,
then
we're
talking
span
versus
event,
but
my
understanding
was
that
it
cannot
return
until
settlement
is
done
because
otherwise,
if
you
first
return
and
then
you
settle
in
the
background,
then
imagine
you
didn't
settle.
Imagine
everything
crashed
right.
You
would
have
to
reprocess
it,
but
the
whole
thing
is
successful.
It's
very
confusing.
G
A
C
I
mean
amazing.
The
scenario
here
is
basically
that
we
have
this
deliver
span.
Basically,
this
delivers
plan
covers
the
callback
that
the
sdk
course
and
basically,
this
callback
ends
once
the
user
returns
from
the
callback
and
then
basically
other
callback
returns
and
after
that
and
based
on
this
callback
restart
the
sdk
then
does
the
settlement
and
that
that's
how
I
understand
it,
how
it
can
work-
and
I
think
in
that
scenario
I
think
the
one
problem
that
maybe
army
wants
to
point-
that
is
that
basically,
the
settlements
by
iteration.
C
This
doesn't
impact
the
user
code
at
all
because
it's
like
for
the
user
code.
Basically,
this
delivery
span
is
the
root
span
and
all
my
operations
underneath
and
then
I
end,
and
then
I
I'm
done
the
return.
And
then
this
delivery
span
is
done
and
then
the
settlement,
then
the
sdk
course
the
settlement
span,
but
it
already
happens
when
the
control
flow
completely
left
yeah.
B
C
C
I
think
that
this,
that
is,
that
is
a
fair
assumption,
but
or
otherwise
we
define
this
delivery
span
to
capture
like
the
user
of
the
process
operation
and
also
the
settlement
operation.
We
defined
it
to
cover
both,
but
currently
my
understanding.
We
only
defined
it
to
cover
only
the
the
processing
operation.
G
I
think
for
auto
settlement.
It
does
make
sense
to
have
it
capture
both
at
least
optionally
and
and
if
you
know
it's
important
to
you
to
be
able
to
measure
the
two
things
with
a
separate
span
separately,
you
you
could
do
it
separately,
but.
G
I
think
to
a
lot
of
applications
that
that
that
won't
be
important
and
then
requiring
that
they
create
extra
spans.
I
don't
know
if
we
should
push
that
onto
them.
G
C
B
I
think
it
could
be
down
through
links
anyway.
I
I
have
a
comment
on
like
we
shouldn't
push
things
on
as
the
case
when
we
give
options
as
the
case
don't
do
a
good
job
right.
If
you
can't
say
okay,
you
don't
have
to
instrument
settlement,
then
they
want
most
of
them
or
they
they
will
do
it
in
some
certain
way
right.
So
if
we
can
be
consistent
and
simple
in
terms
of
guidance,
it
will
help
tremendously
this
instrumentation
and
maybe
the
the
way
to
approach
it
is.
F
I
just
I
just
I
just
thought
about
something:
maybe
it's
stupid,
but
when,
when
the
settlement
is
called
in
this
case,
we
don't
have
the
message
at
that
point
right.
That
has
been
settled,
because
if
we
have
the
context
in
the
message,
then
the
setup
process
could
just
add
a
link
right
to
this
context.
That's
in
the
message,
then,
then
everything
would
work,
but
I
don't
don't
think
the
settlement
has
the
message
right.
Just
do
something
or
or
does
it
have
the
message
you
can.
F
Like,
for
example,
in
this
case
that
the
user
calls
the
ack
function,
does
the
act
function
receives
the
message
that
is
being
act
or
is
just
because,
if
that's
the
case,
if,
if
that's
the
general
case,
then
wouldn't
we
be
able
to
instruct
them
if
they
want
to
create
a
stand,
that
they
can
add
a
link
or
they
should
add
a
link
and
then
the
and
then
you
can
pretty
much
link
them
together.
Right
then,
the
the
issue
with
the
delivery
span
ending
afterwards.
It's
not
a
problem
anymore.
A
Actually,
I
made
these
few
drawings
of
a
few
possible
linux
situation.
Maybe
we
can
very
quickly
breathe
over
them.
So
what
I
want
to
suggest
is
that
the
settlement
span,
because
we
we
don't
know
where
it
can
be
in
the
trace
like
it-
can
be
within
a
new
trace.
It
can
be
the
child
of
the
deliver
it
can
be
like,
like
maybe
the
delivery,
it's
a
manual
spin
and
the
settlement
comes
after
it,
so
we
we
can't
know
for
sure.
A
A
F
A
A
It's
an
implementation
question
like
on
the
spec
level.
I
I
think
that
if
it
is
possible
to
add
a
link
from
the
settlement
to
the
delivery,
then
I
think
we
should
consider
it
because
it
can
really
help
correlate
everything
when
you
have
like
multiple
traces
of
multiple
messages,
and
you
can't
guarantee
the
order
of
spends
within
these
traces.
A
But
if
it's
impossible,
then
for
sure
we
cannot
tell
someone
to
do
something
if
it's
not
possible
technically,
so
only
if
it's
possible.
A
So
this
is
the
second
example.
We
have
the
settlement,
it's
the
direct
child
of
the
deliver.
So
in
this
case,
what
I
want
to
suggest
is
that
the
link
is
optional.
So
if
the
link
is
missing
and
and
the
settlement
is
a
child
of
the
delivery,
then
like
it
means
that
it's
a
settlement
of
the
delivery
of
this
of
the
messages
in
this
delivery
that
are
involved
in
this
delivery,
and
the
other
case
is
that
settlement
is
not
a
direct
child
of
the
delivery.
A
F
A
B
I
wonder
what
limitations
are
there
because
imagine
I
write
my
code
I
receive
and
then
I
do
my
processing
and
the
user
record
and
then
I
settle
and
then,
if
I
do
it
message
by
message,
then
I
can
link
or
correlate
in
some
other
ways.
But
if
it's
an
offset
based
thing,
there
is
no
way
to
correlate
the
delivery
and
settlement
right.
A
Yeah
yeah
you're
right
like
I.
If
something
is
not
possible
technically,
then
of
course
we
cannot
tell
people
to
do
it
like.
I
only
suggest
it
for
the
places
where
it
makes
sense,
and
but
maybe
we
can
examine
an
example
with
a
checkpoint
settlement
and
and
see
what
we
want
to
suggest
to
to
the
specifications.
So
we
cover
everything
that
we
can
for
these
cases,
because
I
think
if
we
just
do
settlement
but
have
no
link
or
no
attribute
saying
which
messages
are
involved,
then
it's
worthless
right.
A
B
Yeah
yeah
so
like
there
are
two
different
beasts:
the
per
message
settlement,
which
we
have
the
rough
idea,
how
to
do
and
just
minor
concerns,
and
then
there
is
a
checkpoint
settlement.
A
Actually
for
checkpoint
settlement,
we
have
the
offset
and
then
like,
if,
if
a
back-end
system
really
wants
to,
it
can
take
this
offset
and
the
offset
of
of
the
the
other
spans
that
are
that
is
attached
as
a
spin
attribute
and
like
understand
what
is
being
settled
in
this
operation.
But
well,
we
need
to
look
at
an
example.
A
A
G
Try
to
throw
a
few
more
thoughts
out
on
on
the
concept
of
an
optional
settlement,
so
where
I'm
coming
from
with
that
is
I'm
thinking
of
our
messaging
system,
and
I
don't
see
value
in
in
creating
an
extra
settlement
span
and
the
reason
is
because
it's
a
it's
a
very
short
duration
thing
and
so
to
create
a
span
for
something
that's
effectively.
G
No
duration
feels
like
a
bit
of
a
waste
and,
and
so
for
to
me,
it
would
make
more
sense
to
have
a
single
span
encompass
everything
with
an
event
in
demarcating
where
the
callback
ended
for
for
the
application
and
and
what's
what's,
and
I
think
I
think
if
we
were
to
make
it
optional
kind
of
to
your
point
with
mueller.
You
don't
want
to
give
people
options
to
implement
things
in
a
bad
way.
And
so
maybe
we
need
to
provide
guidance
on
when
it
can
be
omitted.
G
But
you
know,
maybe
if
it's,
if
it's
like
a
very
short
duration
operation
or
like
if
you're
the
different
messaging
semantics
that
are
often
referred
to
messaging,
are
like
at
least
once
exactly
once
or
at
most
once
at
most
once
usually
has
no
settlement
involved,
it's
sort
of
real
time,
it's
the
least
overhead
and
most
efficient
you
just
kind
of
stream
the
messages
through
as
they
come
in
and
you
get
what
you
get
and
if
things
get
lost,
you
don't
care
and
then
there's
at
least
once,
which
is,
I
would
say,
one
of
the
most
common
I'd
say
it's
far
more
common
than
exactly
once,
and
the
reason
is
that
exactly
once
usually
fails
to
deliver
on
the
promise
exactly
once
and
so,
applications
have
to
implement
the
ability
to
get
messages
more
than
once
anyways
or
handle
it
in
some
graceful
way,
and
so
people
don't
want
to
pay
the
price
of
exactly
once
and
if
and
with
at
least
once
where
you
can
get
the
message
same
message
delivered
multiple
times.
G
It's
it's
possible
to
implement
settlement
in
a
way.
That's
that's
very
short
duration,
whereas
with
exactly
once,
you
have
to
have
a
round
trip,
you
know
to
to
the
person
who
sent
the
message.
So
I'm
wondering
if
some
of
this
could
be
put
into
some
guidance
around
when
you
would
need
a
settlement
span.
B
G
Well,
not
in
the
auto
settlement
case,
but
in
the
in
the
in
the
user's
user
invoked
settlement.
It
does
involve
a
method
on
the
api
and
in
that
case
I
do
wonder
if
you
might
want
that
in
the
in
those
cases
to
generate
a
span,
because
you
want
to
record
the
outcome
right
where
it's,
it's
still
a
smelly
span
where
there's
no
duration,
but
if
they
didn't
create
the
instrumentation
to
indicate
the
outcome,
you
would
not
have
that
information.
So
I
think
in
that
case
you
may
want
to
span.
F
Should
we
should
we
compile
some
of
the
conclusions
that
we
just
reached
in
in
some
place,
so
we
have
a
point
to
start
next
week,
so
we
said
that
we
said
that
if,
if
is,
if
it's
a
remote
operation,
then
we
probably
should
recommend
creating
a
a
setup.
Maybe.