►
From YouTube: 2023-02-09 meeting
Description
Instrumentation: Messaging
A
A
A
A
A
A
B
A
D
A
A
Here
and
yet
ended
up
three
people
added
their
time
preferences
here
that
was
shower
and
Tyler
and
me,
and
we
turned
out-
is
that
there's
two
time
slots
where
all
of
us
have
time
the
one
would
be
Monday
ATM
and
the
other
would
be
Wednesday
pay
them.
A
A
A
Okay,
let's
have
a
look
at
the
at
the
board.
There
is
one
thing
that
Carlos
started
in
the
spec
meeting:
it's
resurrecting
this
this
PR
for
allowing
links
after
spend
creation.
A
He
talked
about
that
in
the
spec
meeting
on
Tuesday
there
was
there
were
not
any
concerns
kind
of
expressed
there,
so
we
opened
the
pr
and
yeah
it's
off
to
a
good
start.
So
far
we
already
have
some
approvers.
A
Let's
see
it's
loading
here,
the
main
the
main
pushback
we
have
is
from
the
go
community
because
they
say
adding
additional
like
methods
to
their
span.
Interface
would
would
have
both
would
cause
some
headaches
for
them
and
their
users
I
think
we
can
sort
it
out,
but
yeah.
Let's
see
I
expect
that
we
will
talk
about
this
issue
in
in
next
week's
spec
meeting
again.
A
Yeah
we
already
have
some
approvers
from
some
quite
important
people
here
and
there
are
some
discussions
going
on,
and
mainly
it's
CR
related
to
the
effects
that
this
will
have
on
the
on
the
on
the
go
on
the
goldlink
people,
but
yeah,
let's
see
I'm
pretty
sure
we
can
sort
it
out.
It
was
also
already
talking
with
Tyler
yarn
from
the
ghost
side,
and
if
they
really
don't
want
to
go,
have
this
additional
method
in
the
interface.
A
Maybe
there
can
be
like
a
compromise
for
the
go
people
that
they
just
he,
for
example,
said
it
would
be
possible
for
them
to
add
links
on
the
span
and
method
and
if
that's
the
only
way
for
them
to
do
it,
I
think
there's
room
to
kind
of
revert
this
back
language,
that
the
other
gopeople
have
to
freedom
to
do
that.
But
let's
see
if
it
if
that
will
even
be
necessary
foreign.
A
This
will
M.
This
will
then
unblock
some
of
our
some
of
the
things
we
propose
here
in
this
Otep
for
this
main
structures
for
messaging
scenario,
because
we
said
yeah,
we
don't
want
to
really
compromise
there
and
we
want
to
push
for
those
scenarios
that
require
adding
links
after
span
creation.
A
And
so
yeah
that
is
here
in
in
addition
and
I
said
last
time,
I
will
spend
some
time
on
this
issue.
A
I
did
I
added
some
comments
here
to
this
one
and
I
put
on
the
trend
that
we
discuss
about,
especially
about
the
consumer.id
attribute,
because
some
things
are
unclear
for
me,
but
yeah
I
put
that
at
the
at
the
end
of
the
gender,
because
we
were
pushing
off
via
some
other
points
that
I
want
to
get
to
today,
and
maybe
I'll
be
just
manage
that
we
saved
the
last
10
minutes
for
this
to
go
over
this,
maybe
just
to
given
us
context
that
people
can
comment
on
the
pr
and
let's
get
started
with
those
with
those
points
here
that
we
already
are
delaying
from
last
week,
maybe
maybe
Tyler.
A
You
want
to
start
here
about
the
processing
span.
G
Sure
so
in
the
spec
there
is
reference
to
this.
This
notion
of
a
processing
span,
but
it's
not
really
specked
out
I
think
it
was
kind
of
punted
as
a
for
future
specification
right.
G
Yeah
so
over
the
past
a
month
or
so
that
I've
been
involved
in
the
Sig.
One
of
the
things
that
I've
been
interested
in
is
improving
the
relationship
between
different
traces
involved
within
a
pipeline
of
messages
right
and
so
in
the
past,
I've
I've
pushed
for
you
know
trying
to
change.
G
The
semantics
between
you
know
span
links
to
parent
child
in
a
more
generic
sense,
but
after
further
discussion
with
Ludmila,
for
example,
I
I
came
to
the
realization
that
the
processing
span
is
probably
the
the
place
where
I
feel
that
could
have
the
biggest
impact,
and
it's
not
specked
right
now.
So
maybe
that
is
a
good
opportunity
to
to
to
make
that
change.
G
There
I
understand
that
in
a
lot
of
systems,
processing
span
is
difficult
to
Define,
because
you
get
a
a
list
of
messages
and
the
framework
or
the
library
that
is
returning.
G
That
list
of
messages
doesn't
really
have
a
notion
of
what
to
do
with
an
individual
spam
right,
and
so
that
is
certainly
a
good
reason
to
maybe
punt
on
it,
but
I
feel
like
in
terms
of
a
distributed
Trace
having
that
in
terms
of
a
useful
distributed
Trace
having
that
processing
span
is,
in
my
mind,
one
of
the
the
critical
pieces
of
that
puzzle,
because
that's
what
allows
you
to
really
time
how
long
an
individual
message
is
being
processed
and
linking
the
and
continuing
the
chain
of
the
propagation.
A
A
To
give
like
some
some
reasoning
why
we
did
not
did
not
include
the
process
ban,
at
least
until
now,
in
this
kind
of
proposed
spec
changes
that
they
basically
wanted
to
to
come
up
with,
like
a
minimum
of
rules
and
recommendations
to
like
instrument
messaging
scenarios
and
and
this
minimum
that
we
could
settle
on,
did
not
contain
the
process
plan
because
yeah
the
process
band
cannot
be
cannot
be
created
in
all
scenarios,
I
mean
what
you
settle
down.
A
What
we
said:
okay,
arson
nervous,
you
can
either
have
to
receive
or
deliver
span
to
deliver
span
for
the
push-based
scenarios
to
receive
span
for
the
pull-based
scenarios.
We
said:
that's
something
that
the
user
sent
in
particular
messaging
sdks
can
create
in
all
scenarios,
but
the
process
ban
is
something
that
is
very
particular
is
depending
on
the
scenario
in
the
use
case
and
that's
something
we
cannot
require
in
all
cases.
It's
something
we
can
recommend
like.
We
can
recommend
creating
a
process
band,
but
we
cannot
require
it.
A
A
Makes
sense
regarding
to
your
point
what
we
could
do.
We
could
yeah
recommend
the
process
ban
and
we
could
then
give
some
maybe
recommendations
or
requirements
of
how
to
kind
of
integrate
those
process.
Bands
in
a
Trace
like
how
they
should
be
linked,
or
maybe
parented,
to
other
spans
that
somebody
that
something
we
can
probably
give
in
this
pack,
but
I
think
they
cannot
give
like
a
a
more
strong
like
requirement
for
creating
a
process
plan.
No.
G
Yeah
I
get
it
like.
The
specification
can't
say
that
we
must
create
a
processing
span.
I
I
get
that
because
it's
just
simply
not
possible
in
in
some
cases,
but
I
think
that
it
would
be
valuable
to
spec
out
what
that
span
should
look
like.
F
Yeah
I
support
it
and
I
think
those
like
that
could
be
like
a
processing
expense
for
multiple
messages
and
there
could
be
multiple
processing
expense
for
the
same
message
like
it
can
really
be
complex
and
current
specification
doesn't
touch
it
at
all.
So
if
we
do
want
to
to
spec
that
we
have
to
think
about
all
the
combinations,
okay.
G
So
I
guess
in
that
respect,
would
it
be
better
to
kind
of
have
that
as
a
separate
PR
from
this
220.
A
From
my
opinion,
yes,
I
mean
I.
I
would
say
what
we
should
make.
What
we
should
make
sure
with
220
is
that
we
say:
Okay
220
gives
us
a
good
basis
for
integrating
process
plans
later
on
I
mean
we've
already
had
it
in
some
examples
here
and
and
and
basically
that
will
mainly
basically
mainly
that
we
say
okay,
we
have
this.
This
deliver
and
receive
spans
that
are
more
or
less
one.
A
One
of
having
one
of
those
is
more
or
less
required,
and
that's
a
good
basis
for
us
to
introduce
those
those
process.
Bands
I
think
that
is.
That
is
a
step
that
we
should
make
sure
that
the
220
gives
gives
a
good
foundation
to
that,
because
it
would
not
be
good
if
any
changes
then
to
this
model
that
we
propose
here
into
20,
to
introduce
process
pens
later,
but
for
introducing
the
process.
A
G
It
and
and
part
of
the
reason
I
bring
this
up
is
so
I'm
also
involved
in
the
the
the
function
as
a
service
TIG,
the
fastig
and,
where
and
I
feel
like
there's
some
strong
overlap,
specifically
with
regards
to
the
way
that
lambdas
and
sqs
handlers
deal
with
the
way
that
they
structure
their
messages
or
their
spans,
and
so
I
I
feel
like
it's
important
to
you
know,
have
both
in
consideration
and
I.
G
Understand
that
you
know
sqs
is
kind
of
been
postponed
right
now.
The
the
main
focus
here
is
around
Kafka
I.
Believe
I,
think
you
said
previously
that
sqs
was
was
a
later
concern,
but
I'm
just
trying
to
make
sure
that
the
the
work
that's
happening
in
the
the
fast
Sig
can
not
conflict.
A
I
mean
at
least
when
it
I
think
what
the
turmeric
conventions
they
come
up
here
should
work
for
all,
or
at
least
most
messaging
systems,
and
I
mean
it's
just
that
for
for
for
Kafka,
rapid
mq,
like
we
need
to
come
up
also
I
think
that's
that's
a
priority
that
was
set
by
other
people
that
there
is
like
messaging
specific
conventions,
and
that
is
mostly
related
to
attributes
for
those
two,
but
in
terms
of
the
span
structure.
A
I
think
it's
important
that
what
we
come
up
with
here,
Works
generally
yeah
sqs,
and
regarding
what
you
said.
I
completely
agree
with
this-
that
we
need
to
be
aware
of
the
integration
with
pass
and
land.
Then
there's.
B
A
Let
me
see
there
is
there's
an
issue
somewhere
here.
Yes,
it's
this
issue
that
particularly
references.
A
What
you
said
it
was
actually
from
anurag
who
was
at
that
time
at
AWS,
so
I
think
that's
that's.
Basically
the
question
we're
referencing
to
that.
We
are
messaging
fast
and
the
RPC.
Those
are
kind
of
those
semantic
conventions
should
work
in
Tandem
and
there
should
be
a
coherent
story
of
how
to
how
to
how
to
instrument
those
scenarios.
A
We
are
aware
of
this
issue.
I
think
the
anoraki
even
got
I
haven't
seen
this
one
elaborate
example
here,
so
it
might
be
worth
looking
into
that.
There's
been
some
some
discussions
here
and
yeah
I
think
that's
also
something
we
should
figure
out
before
we
bring
messaging
to
like
a
staple
State.
We
should
have
at
least
like
an
idea
here,
and
we
should
have
a.
We
should
be
pretty
convinced
that
what
they
come
up
with
messaging
fits
up
into
the
overall
scenario.
G
So
circling
back
to
the
the
processing
span,
do
you
personally
have
any
concerns
with
my
suggestion
that
processing
spans
parent
should
be
the
remote
spam
as
opposed
to
the
ambient
span,
if
available.
F
G
So
sorry,
you
said
you
do
have
an
issue
with
it.
A
A
This
pool
based
scenario,
basically
where
we
have
a
receive
span
here
with
this
ambient
that
the
triggers
the
receive,
and
then
we
have
the
ambient
that
triggers
the
process
and
the
oven.
We
basically
would
parent
this
process
to
the
related
publish
span
here
then
we
would
end
up
with
with
this
just
ambient
receive
as
a
as
a
Trace.
G
Right
and
that
process
would
have
a
link
to
the
ambient
span,
but
not
be
the
the
child
of
it
is.
Is
my
suggestion.
Foreign
I
understand
that
the
there
are
cases
where
you
know,
processing
a
span
a
day
later
might
result.
In
you
know
a
an
incomplete
trace
or
a
you
know,
a
really
weird
looking
trace
and
to
to
handle
that
specific
scenario.
G
I
was
thinking
that
there
could
be
some
logic
around
conditionally
making
it
the
parent
if
the
the
message
was
created
within
a
certain
time
frame
so
like
in
that
scenario,
if
it's
over,
like
you
know
a
day,
then
it
could
have
the
ambient
and
then
it
could
switch
it
where
the
ambient
is
the
parent
and
the
remote
is
the
the
span
link.
G
The
the
main
thing
I'm
trying
to
get
here
is,
if
you're,
looking
at
a
a
pipeline
of
you,
know,
message
a
is
processed
which
results
in
work.
For
you
know,
further
Downstream
I
think
that
there
is
significant
value
in
being
able
to
see
all
of
the
parts
within
a
pipeline
within
a
single
trace
and
sampled
consistently
and
span
links
just
does
not
provide
that
guarantee.
F
So
I
think
we
talked
about
it
a
lot
in
the
past
and
we
I
think
the
agreement
was
that
we
would
allow
both.
So
we
can
either
allow
it
to
be
the
parent
or
to
be
set
as
a
link
and
user
can
configure,
configure
it
to
the
specific
needs,
but
there's
I
think
it
can
also
be
confusing.
If,
like
you,
create
a
span-
and
you
do
a
processing
inside
the
context
of
this
pen
and
suddenly
this
processing
is
not
Dell.
It's
like
belongs
to
a
different
race.
F
It
can
also
confuse
yourself
and
also,
if
you
do
the
processing
here
in
a
batch,
then
it's
not
possible
any
any
anyway
like.
If
you
have
multiple
parents,
then
you
cannot
do
it.
So
there's
a
lot
of
complications.
F
You
get
a
batch
of
messages
and
you
invoke
a
function
that
receives
an
array
of
messages
and
forces
all
of
them
together,
and
in
this
case
we
cannot
have
a
parent
for
for
the
bosses
batch
step.
So
there
are
cases
where
it's
impossible,
so
I
think
what
we
discussed
was
to
allow
both
cases
and
like
instrumentation,
can
choose
the
default
or
can
be
configured
to
work
one
way
or
another,
but
I
don't
think
we
have
to
acquire
it
to
work
as
a
parent
child
relationship.
E
I
would
like
to
chime
in
here
so
I
think
the
there
are
the
interesting
case
where,
if
we
should
check
this
picture
and
if
it's
the
user,
who
creates
some
ambient
context
and
receives
them
processes,
then
our
user
also
creates
a
process
spend
and
they
do
whatever
they
want.
It
I,
don't
think
it's
it's
the
case
for
our
respect.
E
The
case
for
our
spec
is,
for
example,
Lambda
or
SDK,
or
spring
integration
or
the
service
mesh
who
does
the
receive,
and
then
they
call
process
right
and
the
process
is
actually
practicing
something
on
the
user
application.
Then
they
know
that
there
is
no
ambient
context
right.
For
example,
my
SDK
users
configure
the
process
callback
at
application,
startup
type.
E
If
there
is
an
ambient
context,
it's
something
wrong.
They
don't
want
it.
I
know
it
right.
So
I
think
for
the
cases
like
this,
where
we
know
there
is
no
ambient
context.
User
can
control
it's
the
SDK
choice,
depending
on
their
scenarios
to
say:
okay,
we
wanted
to
be
parent.
We
know
the
parent
is
better
for
a
single
message
case.
E
Then
there
is
other
case.
Okay,
I
don't
know,
for
example,
I'm
instrumenting
HTTP
based
push
thing
and
they
have
ambient
context,
which
is
the
request
from
broker
to
me
right
to
my
application.
I
have
ambient
context
and
I
also
have
a
context
in
the
message.
What
should
I
do
and
I
think?
It's
maybe
an
esoterical
case,
I,
don't
know,
but
maybe
not
anyway,
but
I
think
we
should
not
change
the
invariant
that
okay,
we
always
have
him
in
context.
As
a
parent
like
the
the
context
my
spend
happened
in
is,
is
my
parent.
E
But
this
comes
with
me:
Taylor
I'm,
trying
to
understand
what
here
does
not
work
for
you.
What
you
want
to
improve
in
this
world.
G
So
I
guess
in
that
scenario,
which
is
the
default?
If,
if
we
have
a
configurable
option,
where
you
know
the
the
process
could
default
to
the
ambient,
is
the
parent
or
the
remote
is
the
parent,
which
is
the
default.
E
So
if
I'm
instrumenting,
Columbia
or
some
place,
where
users
have
no
way
to
inject
the
same
bit
context
right,
then
I
should
do
the
remote
message
is
default.
E
A
I
mean
I
I
would
like
you
to
add
something
to
what
Tyler
said,
because
I
I
think
I
understand
where
Tyler
is
coming
from
and
what's
the
motivation,
because
I
also
heard
that
from
some
users
I
think.
The
motivation
is
that
you
have
the
publish
message
from
here
and
you
have
the
process
message
one
here
and
basically,
if
you
want
to
know
the
end-to-end
duration
for
processing
this
message,
you
need
to
basically
get
the
start
time
here
and
the
end
time
from
this
band,
and
the
easiest
way
for
this
is
to
have
them
just
all.
A
In
one
phrase:
yes,
publish
and
one
parenting
to
process
M2,
you
have
it
in
one
trace
and
the
duration
of
this
Trace
basically
is
also
the
end-to-end
duration
from
processing.
This
message
and
I
I
think
that
is
what
Tyler
wants
to
wants
to
achieve.
But
they
also
think
in
previous
discussions
that
we
have
that
we
had.
A
We
came
to
the
conclusion
that
this
is
very
hard
and
almost
impossible
to
bring
cheap
that
via,
like
some
general
specification
and
that's
why
we
came
up
with
this
more
like
complicated
and
roundabout
model,
but
because
what
you
have
to
do
here,
you
basically
do
a
calculator,
end-to-end
duration.
A
You
would
need
to
follow
this
link
and
then
inside
this
trades,
where
somewhere
indirect
way
go
to
this
process
pan,
and
it's
not
easy
to
come
from
this
publish
here
then,
via
this
link
and
this
relationship
to
this
process,
pane
here
and
then
say:
okay,
that's
the
end-to-end
duration
from
processing
message.
One.
A
That
is
something
that
we
can,
that
we
can
add
as
a
recommendation
that
we
have,
that
is
okay
process
band
also
has
a
link
to
the
blockage
plan.
Then
it's
admit
a
bit
easier,
but
it's
still
not
as
easy
as
just
having
them
all
in
the
same
trace
and
just
being
able
to
utilize
the
overall
Trace
duration.
As
the
end.
G
To
end-
and
the
other
thing
I'd
like
to
add,
is
as
soon
as
you
have
span
links
involved,
the
the
sampling
becomes
inconsistent.
So
you
can't
rely
on
the
fact
that
you
know
the
trace
from
publish
M1
is
going
to
be
sampled
the
same
as
the
the
ambient
span
from
the
consumer.
G
Because
those
are
separate
traces,
separate,
Trace,
IDs,
and
so
they
have
separate
independent
sampling
decisions.
G
A
What
we
or
what
I
would
like
to
do
here,
Tyler,
could
you,
maybe
are
you
willing
to
spend
some
time
on
this,
maybe
think
about
this,
and
also
look
at
this
PR
here
to
20
and
see
whether
what
we
came
up
with
here
kind
of
is
a
good
foundation.
B
G
So
help
me,
let
me
get
some
clarification.
Are
we
okay
with
having
process
spam,
be
configurable
to
change
the
parent
in
the
I
I
guess,
based
off
of
what
Ludmila
was
saying
that
if
there
is
no
ambient
span
in
the
case
of
like
sqs
or
whatnot,
where
process
span
could
should
be
the
the
child
of
the
published
span?
G
I
think
that
that's
okay,
I
I,
think
I
can
live
with
that.
I
I
think
that
I
would
like
to
extend
it
a
little
bit
further
and
have.
G
The
SDK
provide
recommendations
for
users
that
so
so
part
of
the
problem
here
is
that
you
know
our.
We
rely
on
a
lot
of
what
we
can
do
with
instrumentation
automatically
right
and
the
Frameworks
don't
necessarily
play
nice
with
that.
It
doesn't
necessarily
give
us
the
the
hooks,
the
the
capabilities
that
we
need.
So
in
the
cases
where
we
can
I
I
like
the
what
ludmilo
is
saying
of
having
processed
just,
you
know
assume
that
there's
no
ambient
span-
okay,
great.
G
Let's
just
have
it
be
a
parent
child
in
cases
where
you
have
like
a
batch
that
is
purely
for
optimization
purposes,
for
example
like
instead
of
having
you
know
a
batch
of
messages
that
are
related
they're,
actually
unrelated
and
you're,
just
pulling
down
a
batch
of
messages
together
for
purely
to
optimize
performance.
In
that
scenario,.
A
A
That
is,
that
is
basically,
that
is
the
push-based
scenario,
and
here
we
already
added
I,
think
that
was
anywhere
based
on
some
discussions.
We
had,
we
said:
okay
in
this
scenario,
it's
up
to
the
to
the
instrument
or
to
decide.
Okay,
do
I,
just
want
to
have
the
link
or
do
I
want
to
have
this
parent
trial
relationship
to
the
publish
Span.
In
addition,
so
I
think
in
this.
A
A
Go
ahead,
I
think
the
complication
comes
then,
when
it
comes
to
to
batching
scenarios
like
when
a
whole
batch
is
delivered.
Let's
see
if
we
have
like.
C
A
We
don't
have
this,
and
here
here's
here's
where
process
bands
come
into
the
picture.
Okay,
so
I
think
it's.
It
might
be
interesting
to
to
see
also
for
your
requirements,
whether
your
requirements
are
satisfied
when
just
looking
at
single
message,
scenarios
or
better
actually
also
have
the
same
requirements
when
it
comes
to
patch
delivery
scenarios
like.
G
Here
I
see
so
so
here's
a
thought
I
think
that
there's
some
inconsistency
there
between
you
know,
deliver
with
a
single
message
and
deliver
with
a
batch
of
messages.
G
In
in
because
this
I
feel
like
there's
different
semantics
right,
so
when
you're
dealing
with
a
batch
of
messages,
you
can't
necessarily
link
have
a
parent
to
the
the
correct
thing.
G
So
I
feel
like
the
the
process.
Message
here
in
a
batch
is
more
similar
to
that
deliver
message
in
a
single,
a
single
message
batch.
A
That
makes
sense
from
one
point
of
view:
I
mean
from
the
other
point
of
view,
but
you
said
okay,
but
the
consistency
that
we
have
here.
It's
the
delivery
span
that
exists
in
our
cases
and
also
the
link
exists
in
our
cases.
So
what
will
be
consistent
is
that
you
have
here.
You
have
this
deliver
operation
modeled
and
this
deliver
operation
always
links
to
the
published
context
of
the
spans
that
are
delivered.
I,
think
that's
the
thing
that
we
have
consistent
and
then
what
we
said.
A
A
From
that
point
of
view,
it's
consistent
from
your
point
of
view
that
is
more
focused
on
your
having
Parent
Trap
relationships.
I
think
you
would
say
yeah
it's
not
consistent,
because
you
have
the
private
right
relationship
in
one
case,
but
not
in
the
other.
E
I
have
a
proposal
here.
It
sounds
like
there
are
a
lot
of
things.
We
don't
know
about
the
Integrations
of
all
sorts
and
different
libraries,
and
it
sounds
like
yes,
the
speaking
out
parts
of
spam
is
a
great
and
I
think
it.
It
has
a
huge
impact
and
I
would
love
to
do
it,
but
we
can
leave
their
relationship
back
for
now,
given
us
future
awesome
room
to
spread
them
out
more
clearly
and
for
now,
if
we
say
okay,
this
is
on
the
instrumentation
library
or
the
instrumented
library
itself
to
figure
it
out.
E
If
you
can
then
believe
in
this
Wagner's
just
allows
us
to
be
more
specific
in
future.
If
we
will
be
specific
now,
we
could
be
wrong
because
we
don't
have
enough
information.
So
how
do
we
feel
about
this
in
this
group?.
A
Yeah
I
I,
think
that
is
a
that
is
for
me,
are
definitely
an
acceptable
way
to
go,
because
also
with
how
this
how
this
PR
is
like
what
this
VR
proposes
now
I
mean
it
doesn't
know
they
prevent
the
process
span
to
parent
to
the
public
spans.
A
If,
if
some
library
or
SDK
does
that,
that's
still
that's
still
fully
in
scope
of
what
we
propose
here.
As
long
as
there
is
some
delivery
span
with
a
link
to
the
publish
span.
B
I
think
what
what
we
could
maybe
do
is
like
if
we
agree,
for
example,
that
the
process
span
is
important,
that
we
we
so,
for
example,
in
a
world
where
this
would
only
be
always
be
possible.
B
Do
we
see
that
this
is
important
to
have
the
process
pen
and,
if
I
think,
if
we
answer
that
with
yes,
then
I
think
that
we
could
say
like
I,
think
it's
that
I
was
saying
like
just
put
it
in
the
spec
saying
like
if
it's
possible
then
do
this
create
this
process
pane,
as
as
a
child
of
of
the
publish
and
I
think
that
gives
us
still
I,
think
some
flexibility
to
to
do
things
in
the
future,
but
also
give
some
guidance
because
I
think
if
we
don't
do
anything
that
I
think
yeah
for
people
writing
the
libraries
I
think
it's
going
to
be
confusing,
maybe
because
they
don't
know
what
what
they
should
be
doing.
B
Even
if
it's
not
a
must,
but
it's
like
a
May
or
something
like
that,
then
I
think
at
least
there's
some
guidance
on
what
to
do
with
the
process.
Pane
I
think
foreign.
G
I
think
one
of
the
the
big
issues
I
have
with
the
with
the
situation
here
is
we're
adding
a
lot.
So
all
of
the
different
style
of
messaging
systems
has
a
lot
of
inconsistencies.
It's
inherently
difficult
to
model
with
high
fidelity.
G
And
I
feel,
like
the
the
most
important
part
of
what
we
are
trying
to
do
as
a
general
product.
A
project
in
open
Telemetry
is
at
least
for
the
the
tracing
side
of
things
is
to
maintain
the
context
of
the
distributed
trace
and
to
be
able
to
link
things
together
to
be
able
to
see
a
bigger
picture
of
how
a
system
is
behaving
and
I.
G
Understand
that
you
know
that's
a
difficult
thing
to
do
with
wildly
different
behaviors
across
systems
and
the
different
messaging
styles,
but
I
feel
like
we
are
making
trade-offs
towards
higher
Fidelity
in
the
the
modeling
of
individual
pieces
at
the
expense
of
keeping
the
the
broader
picture
in
focus.
G
G
I
don't
know
like
the
there's,
a
lot
of
parts
of
the
the
the
traces
that
we're
modeling,
where
you
know
it,
it
might
be
valuable
to
a
very
small
percentage
of
the
users
so
like,
for
example,
the
the
the
time
that
it
took
for
a
receive
is
probably
marginally
beneficial
to
most
use
users,
but
the
time
that
it
took
to
process
that
message,
it
I
think,
is
probably
the
the
most
important
part
and
that's
the
part
that
we
are
kind
of
splitting
up
across
from
the
broader
Trace.
G
By
prioritizing
the
modeling
of
the
the
operations
of
you
know,
consume
produce
receive
commit
all
that
kind
of
stuff
and
I'm
not
trying
to
to
criticize
the
the
work
that
we're
doing
here.
G
I
think
that
it's
valuable,
I
I,
just
from
a
user's
perspective,
I
I,
think
that
it
might
not
be
the
right
Focus.
G
So
what
I'm
trying
to
say
is
that
it
feels
like
a
lot
of
places
that
we
are
talking
about
in
the
spec.
We
are
focusing
on
the
higher
Fidelity
operations,
rather
than
maintaining
the
consistency
of
the
the
trace
and
the
context,
and
the
interactions
between
the
two
I
feel
like
using
links
is
a
very
poor
substitute
for
a
proper
parent-child
relationship
and.
E
G
It
has
very
detrimental
impact
on
the
user
experience.
A
I
think
the
title
is
coming
from.
Basically,
Tyler
would
really
prefer,
like
a
message,
specific
view
that
you
have
okay,
look
at
the
trades
and
this
Trace,
basically
with
current
child
relationships,
give
gives
me
the
Throne
of
this
message
from
beginning
to
the
end.
Yes,
I
think
the
that
might
definitely
be
doable,
I
think
it's
what
we
saw
here
and
but
we
still
see
some
conflicts
with
the
overall
model
of
the
about
to
the
trace
B
and
how
do
it?
How
does
the
trace
operate
model
operations?
A
I
mean
here?
In
this
example,
we
have
here
the
published,
that's
an
operation
that
might
be
triggered
by
by
one
user
and
one
service,
and
then
you
have
basically
this
deliver
operation,
maybe
days
later
in
a
different
service
delivered
triggered
by
different
user.
That
then
starts
a
process.
Operation
and
I
mean
from
another
point
of
view.
You
will
say:
okay,
it's
very
non-intuitive
that
this
deliver
operation
then
starts
on
other
operation.
That
will
be
part
of
a
previous
Trace
that
was
started
days
before
so.
G
So
I
think
that
the
having
having
the
the
separation
of
days
is
a
little
disingenuous
and
probably
not
the
most
common
situation.
I
I
think
that,
having
you
know,
large
separation
and
processing
on
a
message
system
is,
is
relatively
uncommon
or
or
it's
it's
not
the
most
common
situation.
G
A
Is
that
this
this
deliverable
that
will
deliver
will
start
a
new
Trace
in
this
context
and
then
process
basically,
then,
will
suddenly
part
of
a
trace
of
an
other
Trace
that
was
started
before
this
deliver
Trace,
so
you're,
basically
kind
of
attach
this
to
a
trace
that
was
started
before
this
deliver
trades
were
started
and
from
a
point
of
it,
when
you
just
look
at
this
deliver
operation
model,
there's
a
trace
that
do
many
users
might
be
counter-intuitive
that
suddenly
you
trust
your
parent
is.
A
E
E
But
when
we
start
talking
about
okay,
the
single
message
processing
case,
which
is
not
the
only
one
you
become
very
opinionated-
and
we
say:
okay,
we
expect
all
applications
to
run
this
and
we
don't
have
enough
reasons
to
believe
so
right,
maybe
it's
the
case,
but
maybe
not
so
I
think
what
we
are
trying
to
build
is
that
instrumentation
that
can
support
many
applications,
but
in
the
video
instrumentation
libraries
can
be
opinionated,
they
can
say:
okay,
I
view
this
as
a
single
message.
D
The
long-running
traces
like
that,
it
just
seems
to
me
and
I
know
this
isn't
our
effort,
but
it
seems
as
though
there's
more
of
a
recommendation,
I
I
would
I
would
think
if
I
were
writing
it
to
say
you
need
to
send
back
a
heartbeat,
heartbeat
span
or
something
to
the
parent
to
even
say
that
it's
running
because
from
an
incident
response
standpoint,
you
know
if
that
thing
did
crash
you're
losing
hours,
if
not
a
long
time
before
knowing
so
anyway,
that's
more
context
than
it
is
suspect,
specific,
but
I
just
wanted
to
augment
that
with
Tyler's.
D
G
Anyway,
I
guess
just
to
get
to
the
bottom
of
what
I
was
saying
is
I
I
feel
like
our
default
should
be
to
expect
traces
or
a
message
processing
to
happen
in
a
short
period
of
time
and
allow
for
the
the
rarer
case
that
it
takes
days
or
or
hours
or
whatever
is
deemed
a
very
long
time
that
shouldn't
be
the
default.
In
my
opinion,
the
the
default
should
be.
We
expect
things
to
happen
quickly
and
in
a
cohesive,
consistent
fashion.
C
I'll
just
throw
my
my
piece
on
this
I
agree
that
the
sort
of
most
common
use
case
I
would
expect
you
know.
Sort
of
the
event
driven
world
is
that
this
is
all
pretty
real
time
that
events
that
are
produced
are
consumed
and
processed
in
a
short
period
of
time.
And
yes,
there
certainly
are
cases
where
there's
certain
there's
Edge
use
cases,
and
there
are
kind
of
failure.
Cases
where
that
doesn't
happen,
but
I
would
expect
that
to
be
sort
of
the
minority.
F
F
So
for
the
sync
call,
we
know
that
it's
the
same
track
side,
if
you
invoking
an
HTTP
call,
you
know
that
both
the
Grant
and
the
server
belong
to
the
same
Trace,
but
I
think
the
argument
was
that
in
the
async
a
version
then
it
it's
argue
arguably
like
like
it's
not
it's
not
clear.
If,
if
it's
straightforward
for
users
to
expect
it,
as
in
corporations,
spends
the
across
the
choice.
C
I'll
throw
some
thoughts,
I
have
on
that.
Just
because
we've
been
going,
we've
spent
a
lot
of
time
trying
to
implement
tracing
inside
of
our
broker,
which
kind
of
outside
of
the
scope
of
the
spec,
but
we
kind
of
we
kind
of
you
know,
went
back
and
forth
with
this,
like
there
was
sort
of
one
thought
that
okay,
once
a
message
is
persisted
and
now
it's
gonna
go
and
be
delivered
somewhere.
C
Like
you,
don't
know
how
long
it
might
be
persisted
before
it's
delivered,
and
you
want
to
avoid
these
long
traces,
and
so
that
should
be
the
break
and
the
trace
there.
C
But
we
just
looked
at
the
actual
use
cases
like
again
going
back
the
fact
that
the
major
vast
majority
of
messages
are
delivered
very
quickly
and
processed
very
quickly
and
there's
far
more
useful
to
see
that
as
one
trace,
and
so
ultimately,
we
decided
to
do
is
to
just
make
these
all
one
Trace
just
because
we
think
that's
the
most
value
for
the
user
and
as
we
kind
of
get
experience
with
this,
if
the
occasional
case
of
very
long
traces
really
causes
a
problem,
we'll
decide
what
to
do.
Maybe
there's
a
heuristic.
C
Maybe
it's
configurable
about
how
long
a
message
can
sit
before
we
say
forget
it.
That's
the
end
of
this
Trace
we're
starting
a
new
one
or
whatever,
but
you
know,
we
think
that
in
the
most
common
use
case
that
it's
most
valuable
to
have
this
all
be
one
trace
and
and
to
provide
a
continuous
end-to-end
view
of
where
the
message
started
and
where
it
ended
and
where
it
was
processed,
is
of
the
most
important
to
users,
that's
kind
of
where
we
ended
up
yeah.
G
And
and
that
actually
aligns
with
what
I
was
trying
to
propose
of
having
the
the
default,
be
a
complete
Trace,
but
you
know,
if
have
a
configurable
option
of
oh,
this
message
was
created
or
added
to
the
queue
a
long
time
ago.
Okay,
so,
let's,
let's
start
a
new
Trace,
and
that
was
the
the
semantic
or
the
heuristic
I
was
trying
to
put
forward
as
a
way
to
kind
of
work
around
that
particular
scenario.
E
I
think
we
should
keep
this
separate
when
we're
trying
to
limit
the
lens
of
the
trace.
We
are
solving
back
at
visualization
problem
right
if
they
have
a
special
experiences
to
show
something
in
the
window
to
detect
failures
to
the
tailbase
sampling
or
if
they
want
to
show
a
nice
graph.
It's
the
backup,
visualization
problem.
It's
not
the
data
collection,
the
problem
right.
We
should
not
solve
it
with
configuration
in
the
messaging
instrumentations
or
with
the
trace
thing.
E
H
H
Would
I
would
suggest,
because
there's
not
enough
time,
we
document
these
two
options
like
Tyler's
proposal
and
the
original
proposal,
so
we
can
actually
document
them
and
think
about
them.
You
know
when
we
go
to
sleep
or
something
you
know
like.
Basically,
we
just
allow
ourselves
and
our
minds
to
think
about
those
two
options
in
a
calm
way,
identify
also
for
people
like
in
case
these
cannot
be
decided.
We
will
have
to
do
such
exercise
anyway,
so
it
could
suggest
that
as
a
a
task
to
do
this
is
documented.
A
Yeah
to
that
point,
I
I
think
if
I
understand
the
whole
discussion,
all
the
points
correctly
think
it
doesn't
directly
touch
this
PR
anyway,
because
it's
just
about
additions
that
we
have
here
I
mean
these
process
bands.
This
PR
doesn't
make
any
assumption
about
process
bands
and
any
recommendations.
So
what
I
will
do
to
make
it
clear
that
this
is
treated
as
a
separate
topic
from
what
we
propose
here?
A
Think
and
if
others
agree,
I
think
we
can
move
on
and
then
discuss
this
as
a
separate
as
separate
to
this
PR
and
maybe
then
as
a
separate
kind
of
as
a
separate
kind
of
power
outtap
of
how
we
integrate
process
bands
into
this
whole
flow
because
I
think
it
as
far
as
I
can
see
it
should
not.
It
should
not
break
what
we
come
up
here
with
with
the
deliver
and
receive
relationships.
A
I
think
what
we
come
up
here
with
the
element
receive
relationships.
It's
the
best
that
we
can
do
because
here
for
receive.
If
you
receive
a
badge,
we
cannot
parent
and
if
we,
if
we
deliver
a
patch,
we
can
also
not
parent,
and
if
we
can
parent,
we
actually
offer
like
the
option.
Do
we
apparent
those
Deliverance
receive
spends
so
I
think
they'll
actually
be
offer
already
the
most
flexibility
that
we
can
and
for
this
process
case
I
think
yeah.
That
is
an
open
question.
A
We
don't
yet
have
an
agreement
on
that,
but
I
think
we
should
treat
that
as
as
an
addendum
to
this
to
this
PR
and
and
Tyler.
If
you,
if
you
could
maybe
come
up
with
some
proposals
here
or
some
examples,
how
that
can
look
in
some
use
cases.
That
would
be
great
and
maybe
then
we
can
discuss
next
week.
H
Okay,
maybe
we
may
even
create
an
issue.
You
know,
maybe
somebody
liquid,
he
happens
to
have
some
experience
moving
hard.
A
Yes,
we
can
create
an
issue
mean
we
looked
at
this
issue
before
here,
and
maybe
it
Maps
it
Maps.
Well,
anyway,
to
this
existing
issue,
maybe
title
you
can
have
a
look
at
the
at
nine
9,
36
and
963,
and
and
and
and
see
whether
that
covers
because
it
has
kind
of
an
example.
Here.
Maybe
you
can
see
better
that
covers
your
requirements,
because
we
already
have
that
on
our
our
board.
B
A
And
also
Carlos,
we
we
we
decided
to
be
that
we
want
to
have
an
other
meeting,
Monday
8
A.M,
to
kind
of
make
better
progress.
Is
it
possible
to
somehow
get
that
on
the
calendar.
A
Awesome,
so
we
are
one
minute
past
time
thanks
everybody
thanks
for
joining
thanks
for
Tyler,
for
linking
us
to
the
fast
and
the
Lambda
group
I
think
that's
very
valuable
for
us
cool
yeah,
no
problem,
just
somebody
who's
who's
active
in
both
groups
and
helps
us
understand
their
requirements
and
then
yeah.
That's
each
other
next
week,
either
Monday
or
on
Thursday.