►
From YouTube: 2020-11-10 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).
B
A
A
B
Yeah
it
looks
like
the
usual
group
and
it's
about
the
usual
time
so
yeah
should
I
get
into
a
recap
of
the
spec
sig
and
do
we
have.
A
I
think
there's
some
people,
I
know,
but
nothing.
For
me.
I
have
one
or
two
questions
around
some
pr's
I
reviewed,
but
I'm
more
want
to
make
sure
robert
has
time
for
any
questions.
If
you,
if
he
has
questions
around
rails
or
is
anything.
C
The
rails
stuff,
I
think,
is
up
for
review.
It's
pretty
simple,
but
I
think
it's
a
decent
starting
point.
So
we
could
maybe
go
over
that
before
or
after
I'd
like
to
take
like
a
hot
second
to
talk
about
your
graphql
pr,
just
because
I've
been
doing
a
bit
of
the
stuff
on
our
internal
tracing
stuff.
So
I
don't
know
if
you
guys
can
do
that
before
after,
but
leave
that
to
the
crowd.
A
B
B
B
Yeah,
so
there
are
a
handful
of
issues.
I
think
that
are
still
open
keeping
tracing
from
gaying,
but
there
was
kind
of
this
discussion
a
little
bit
about
like
what
exactly
does
ga
mean
and
how
are
they
going
to
advertise
it?
It's
like
I
don't
know
some
users
are.
I
think
it
can
be
confusing
to
users
as
to
what
exactly
me
this
means
and
what
is
usable
and
what
is
not,
but
ultimately
ga
is
not
going
to
mean
like
a
1.0
for
for
hotel
but
yeah.
I
don't
know
this.
B
This
conversation
was
shut
down
a
little
bit
by
the
crowd,
saying
that
this
is
really
kind
of
for
the
gc
for
the
governance
committee
to
to
decide.
B
So
we
actually
got
into
the
issues.
There's
this
issue
about
the
otlp
port
and
I
guess
open
telemetry
is
using
this
port
55680
and
they
wanted.
B
B
B
B
B
B
B
It
looks
like
this
is
the
suggestion
that
that
they
can.
B
I
still
don't
know
what
that
means
exactly.
I
don't
know
if
it
means
if
they
should,
but
it
looks
like
they
can.
B
But
yeah,
I
think
that
was
the
thing
alolita
who
works
for
aws
was
going
to
do
some
sort
of
follow-up.
I
think
there's
there's
some
back
and
forth
about
just
like.
I
think
the
discoverability.
B
B
This
spec
or
the
spec
is
saying
that
no
value
should
not
be
allowed
even
in
arrays.
I
don't
know
the
things
that
were
interesting
about
this
conversation,
most
of
it.
B
It's
not
that
interesting,
but
I
think
just
hearing
what
other
dynamic
language
people
are
doing
in
other
dynamic
languages
around
validating
their
arrays
and
it
seems
like
I
know,
we've
had
concerns
and
discussions
here
just
about
like
the
cost
of
some
of
the
validations
that
we
have
to
do.
The
runtime
validations
and.
D
B
B
D
Most
of
our
validation
right
now
is
done
when
we
create
spans
and
when
we
add
attributes
so
we're
kind
of
doing
it
eagerly
we're
doing
it
somewhat
eagerly.
D
Part
of
the
rationale
for
that
is
that
we
want
to
avoid
holding
on
to
a
bunch
of
stuff
that
might
end
up
being
dropped
in
the
batch
band
processor
or
later
in
the
pipeline,
so
holding
on
to
a
bunch
of
garbage
effectively
that
we're
just
going
to
drop
anyway.
D
Has
been
our
choice,
I
don't
know
if
it's
the
right
choice,
but
suddenly,
if
you're
doing
like
truncation
of
attributes,
large
attributes
as
an
example,
it's
nice,
if
you
do
that
truncation
early
rather
than
waiting
until
later
on.
The
counter
argument
is
that,
like
there
is
some
work
involved
in
doing
that
truncation,
so
maybe
you're
better
off
just
waiting.
I
don't
know
it's
a
trade-off
like
ruby's
at
least
mri's
garbage
collector
is
not
terribly
efficient,
so
trying
to
save
it.
Some
work
seems
like
a
nice
thing
to
do.
B
B
This
yeah,
this
approach
seems,
seems
reasonable
and
we've
thought
about
it,
and
we
have
a
good
story
for
for
why
we're
doing
it?
The
way
we
are
well
on
that
note,
this
is
not
in
the
spec
meeting,
but.
D
B
B
B
And
then
just
kind
of
this
last
thing
was,
I
don't
know,
I
think,
there's
there's
some
yaml
tool
around
for
creating,
I
think
markdown
from
emo
for
semantic
conventions,
and
this
person
was
trying
to
use
it
for
metrics
and
found
that
the
tool
was
somehow
coupled
to
trace
and
was
just
discussing
fixing
that
so
it
was
more
generic
and
then
the
fact
that
he
he
was
kind
of
having
to
fix
something.
B
Finding
some
instances
where
you
had
to
make
some
like
minor
changes,
minor
insignificant
changes,
but
things
that
would
probably
show
up
in
a
diff.
So
I
think
he
was
just
kind
of
asking
about
about
that
whole
process
and
giving
people
a
heads
up.
This
conversation
was
still
kind
of
going
on
when
I
left
meeting
ran
over
a
little
bit,
but
generally
that
was
the
spec
sig.
D
B
Yeah,
so
I
guess
that
everybody's
doing
it.
B
Well,
I
think
that's
a
special,
I
know
when
we
started
off
I
I
guess
any
any
questions
comments
concerns
anything
we
should
continue
talking
about
there.
D
The
nullable
values-
I
don't
think
we're
doing
anything
special
for
nulls
at
the
moment
in
arrays
or
otherwise.
So
that
may
be
something
that
we
have
to
look
into.
I
know
our
documentation,
it
doesn't
explicitly
say
you
can't
have
null
values,
but
it
doesn't
list
null
as
an
acceptable
value,
but.
C
B
B
B
So
this
is
wrong
naming
and
then
some
just
suggestions
around
like
when
when
this,
when
these
validations
should
happen,
but
I
do
think
we
should
finish
this
off
at
some
point
in
time
or
at
least
look
at
it
and
see
if
it's
something
that
we
want
to
finish
off.
B
D
Yeah,
it
looks
like
the
spec
doesn't
say
anything
at
the
moment
about
this
additional
validation.
D
In
fact,
we
may
support
more
validation,
because
I
think
we
basically
did
what
java
did
and
java
supports
more
than
just
the
three
items.
D
B
Yeah,
so
if
I
recall
like
one
of
the
reasons
why
this
showed
up
and
one
problem
we
still
kind
of
have-
is
that
like
there's,
if
you
do
have
like
a
a
null
attribute,
a
nil
like
the
jager
exporter
at
least,
will
fail
fail
to
export
things
like
things
break
in
the
export
pipeline,
because
that's
not
an
expected
condition.
B
D
Is
that
something
we
should
be
fixing
in,
I
mean
obviously,
we
need
to
fix
novel
handling,
but
that
kind
of
knowledge
check
is
that
something
that
should
be
fixed
in
the
jaeger
exporter,
given
that
it's
explicitly
broken
by
that
or.
B
Yeah,
I
feel
like
there's
a
few
approaches
to
that,
like
it
seems
like
it's
an
easy
fix
to
apply
in
the
jaeger
exporter.
B
At
the
same
time,
it
would
be
like
it
would
be
really
nice
and
ideal
if
we
just
didn't,
let
anything
bad
into
the
export
pipeline.
But
maybe
maybe
we
should
let
that
stuff
in
the
export.
Quite
fine
and
just
let
the
export
pipeline
handle
the
handle
that
data
I
I
guess
it
depends
on
like
where,
where
do
you
want
to
solve
the
problem?
D
Yeah,
I
think
we
should
certainly
support
what
the
spec
requires
so
that
the
exporters
won't
see
anything,
that's
not
allowed
by
the
spec.
But
if
the
exporters
also
have
additional
limitations,
then
we
need
to
handle
those
in
the
exporters
themselves.
So
the
null
one.
You
know
now
that
they've
clarified,
hopefully
exactly
what
has
to
be
done
for
nulls.
D
We
can
implement
that
validation
in
the
sdk,
but
for
like
jaeger,
doesn't
handle
array
attributes,
for
example,
so
or
like
array
value
attributes.
So
there
we
need
to
handle
those,
especially
by
converting
them
to
json
encoded
strings.
B
B
I
don't
know
if
you
want
the
screen
you're
more
than
welcome
to
take
it.
If
not,
I
can
navigate
from
here
my
screen's
a
mess,
so
I
would
absolutely
prefer
if
you
did.
C
Tell
me
what
what
to
do
yeah,
just
open
up
the
pr
and
go
to
the
files
change
and
we
can
just
like.
I
can
just
kind
of
talk
through
what
I
did
and
we
can
look
at
if
any
of
it
makes
sense
so
that
rid
of
the
topic.
This
is
kind
of
what
came
out
of
some
discussions
with
francis
and
a
bit
about
from
one
last
time
we
talked
about.
C
It
was
extending
rack
to
be
reusable
for
like
sinatra,
rails
and
rota
me
whatever
poison
you
want,
and
the
idea
here
is
that
now
in
the
rack
trace
your
middleware
it'll
wrap
the
middleware
call
with
context
and
so
like
a
with
it.
The
current
span
so
that
anything
downstream
from
the
call
say
like
rails
metal
will
check.
So
if
you
go
to
metal
or
b
in
here,.
C
It's
it's
pretty
simple,
so
it's
just
grabbing
the
rackspan
and
made
it
really
simple.
So
if
there's
a
rackspan
and
it's
not
an
action
dispatch
exception
like
if
that's
not
set.
So
this
is
like
the
case
where
your
controller
raises
an
exception
and
someone
has
the
exceptions
app
configured
and
then
the
exception
app
would
catch
it
again.
So
we
don't
want
to
overwrite
the
rack
name
or
the
span
name.
I
should
say,
with
the
exceptions,
controller
app.
We
want
to
leave
it
on
the
controller
that
originally
raised.
So
that's
the
logic
behind
that.
C
Some
of
the
like.
I'm
not
sure
if
I
call
this
like
the
stinky
parts
but
like
if
you
scroll
down
just
a
little
bit
to
the
rail
tie,
there's
some
weird
interactions
with
installing
instrumentation
and
I
feel
like
there's
potentially
a
problem
there
that
I'm
not
seeing,
but
I
don't
see
it
so
like.
If
you
look
in
the
before
initialize,
we
try
to
install
the
rack
instrumentation
there
so
right
before
we
set
up
the
middleware,
we
try
to
install
it.
C
So
you
can
actually
overwrite
this
by
in
the
sdk
configuration
explicitly
installing
rack
instrumentation
as
a
dependency
and
it'll
take
that
config
over
this
one.
But
this
one
will
just
try
to
install
it
if
it
hasn't,
so
you
can
explicitly
configure
the
rack
middleware,
the
normal
way,
which
I
thought
was
a
good
idea,
but
it's
not
required.
C
C
I
didn't
want
to
change
a
lot
of
like
the
configuration
interface
that
felt
like
that
could
get
pretty
out
of
hand.
Pretty
quick-
and
I
didn't
like
I'm
trying
to
keep
the
two
decoupled
right,
but
rails
does
depend
on
rack
and
I
think
that's
okay
to
have
that
dependency,
but
I
don't
want
rack.
I
want
to
make
sure
that
rack
has
no
changes
that
depend
on
rails.
That
obviously
would
bite
us
in
the
ass.
B
C
A
Is
there
a
reason
we
don't
do
like
app.middleware
dot
insert
before
or
something
along
those
lines
like
just
insert
the
middleware
versus
yes,.
C
There
it
is
so
I
started
with
that
and
as
if,
like
I've
alluded
to
before,
like
that
for
our
not
in
production,
yet
implementation
of
hotel
shopify,
we
have
a
wrapper
gem
and
we
use
a
rail
tie
to
initialize
and
configure
everything.
C
So
when
I
started
working
on
this,
I
was
using
that
I
was
using
that
on
a
little
test
app
I
have
internally,
and
so
the
rail
tie
just
kicks
everything
off,
there's
no
rails
initializers,
and
so
I
got
pretty
far
along
with
all
this
stuff,
and
I
was
like
oh,
I
should
probably
test
this
without
using
a
rail
tie
like
without
using
our
like
shopify's
wrapper
gem,
so
I
switched
to
just
using
the
typical
configuration
and
this
it's
too
late
in
the
initialization
cycle,
and
none
of
this
would
actually
run
another
code.
A
Right
right,
sorry,
I
misspoke
slightly.
I
apologize
within
so
right,
it's
frozen
if
we
call
it
too
late,
the
middleware
stack
is
frozen,
but
within
before
initialize,
I'm
I'm
basically
just
looking
at
what
datadog's
done
and
seeing
and
then
diffing
it
seeing
what's
different
within
the
before
initialize.
A
We
just
call
app.middleware
before
like
zero,
we
insert
trace
middle.
We
insert
the
rack
middleware
at
the
very
start
of
the
middleware
stack.
A
D
Yeah,
so
we
don't
in
install
by
default
in
the
rack
instrumentation,
you
have
to
do
it
explicitly
here,
we're
doing
it
explicitly.
There
is
that
discussion
item
there
in
our
in
shopify's
instrumentation.
D
We
do
actually
capture
the
request
id
as
a
tag
or
an
attribute
on
the
span,
which
is
why
we
insert
it
after
the
action
dispatch
request
id
we're
not
actually
doing
that
at
the
moment
in
this
rails
instrumentation.
So
arguably,
we
should
do
what
you're
suggesting
and
install
it
at
the
bottom
of
the
stack.
A
D
A
Yeah,
I
think
it's
I
mean
that's
like
the
most
useful
tag
in
rails
kind
of
so
I
think
I
am
fine
with
cuba.
I
honestly
just
was
looking
at
the
wrong
line,
so
I've
just
been
rambling.
I
think
it's
fine,
I'm
not
super
picky
about
the.
Where
we
put
the
rack
thing,
the
only
other
thing
I'd
say
is
like
datadog
has
some
do
we
know
if
the
request
id
do
we
know
if
we're
if
we're
inserted
like
there's
some
ex
there's
some
exception
handling
middleware?
A
That
might
swallow
errors.
That's
the
only
other
thing
to
worry
about
is
there's
this
action.
Dispatch
dispatch,
show
exceptions
middleware
and
if
we're
inserted,
I
guess
before
it
after
earlier.
C
This
is
earlier,
so
the
request
id
is
executes
before
the
the
exceptions
happen.
C
D
Yeah
in
shopify's
instrumentation,
we
had
two
middlewares
one
that
was
like
our
existing
rack
middleware
and
then
a
rack
error
middleware
that
we
would
inst
insert
after
show
exception,
so
that
you'd
get
to
see
the
exception
and
add
it
as
tags
on
your
span
before
show
exception,
just
kind
of
swallowed.
It
we're
not
doing
that
here,
we're
doing
something
a
little
bit
different.
D
C
So
I
think
I
don't
think
we're
it's
not
too
too
much
different,
like
I
guess
I'm
for
this
one.
The
difference
between
like
shopify,
one
which
ones
you
guys
don't
see
is
I'm
just
relying
on
the
rack,
middleware
behavior,
the
existing
behavior
but
cause.
I
didn't
didn't
build
that
one
out,
but
I
have
confidence
that
it
works
as
intended.
So
I've
just
like
used
you're
talking
about
the
error
handling
because
we
have
the
error
adapter
right,
the
racketer
adapter
right.
I
guess.
C
B
C
A
And
it's
yeah,
I
think
the
concern
is
more
yeah.
It's
I'm
not
sure.
I
guess
I
will
have
to
look
at
what
the
data
dog
has
some
extent
as
well.
So
maybe
I
can
look
and
see
if
there's
some
case,
that's
common
enough,
that
we
should
try
to
account
for
it.
But
it
sounds
like
it's
fine.
What
we're
doing
is
fine
yeah.
C
And
then
I
guess
I'm
just
trying
to
think
of
like
points
of
potential
interest,
maybe
just
for
a
quick
looky-loo
overall
here
at
the
very
top
of
the
pr
or
the
second
file.
Is
the
tracer
middleware
changes.
I
added
the
http
agent,
so
just
scrolling
a
little
bit,
so
it
changes
pretty
small.
C
So
this
is
this
is
what
wraps
the
call
with
the
rackspan,
which
is
what
makes
it
available
in
metal.
I
had
an
http
user
agent
there.
I
think
this
is
a
fairly
innocuous
change.
Didn't
want
to
make
too
many
changes
there.
C
One
of
them
should
be
the
metal
rv
test,
just
to
see
kind
of
the
expectations
that
put
like
the
expectations
of
the
behavior,
there's,
still
a
risk
of
really
high
cardinality
in
the
spans
that
come
out,
because
I'm
not
handling
things
that
don't
reach
the
action
controller,
so
there's
no
predicting
the
route
or
like
based
off
of
the
information
so
that
first
test
there
is
a
little
bit
longer.
It's
a
lot
of
that
is
just
testing
stuff
that
exists
in
iraq.
C
I
didn't
want
to
duplicate
more
than
I
needed,
but
I
think
it's
good
to
just
I
like
test
as
documentation.
So
I
think
this
is
helpful.
Someone
can
look
at
what
they
can
expect
to
come
out
of
this
if
they're
curious,
but
then,
after
that,
it's
really
metal
is
just
changing
the
name
of
the
rackspan.
So
that's
where
all
those
assertions
come
after,
so
you
can
see
that
a
lot
of
them
will
just
preserve
the
existing
path.
Name,
that's
set
by
the
rack
middleware.
C
In
the
case
of
an
exception
being
raised,
you
can
see
that
it
still
preserves
the
controller
name
and
action
and
in
the
case
of
an
exceptions
app
at
the
last
spec
there,
it's
using
the
exception
app,
but
we
don't
overwrite
the
the
original
controller
name
and
action
with
the
exceptions
out.
So
this
this
doesn't
double
overwrite
the
rack's
band
name,
and
that's
really
the
bulk
of
what
this
pr
is
doing.
That
is
just
adding
a
name
to
a
span
or
overriding
the
name
of
spam.
C
C
C
So
there
I
made,
I
require
open
to
limit
oh
scroll
up
just
a
little
bit.
We
can
just
it
might
make
sense
to
go
from
that
class
down,
so
the
open,
telemetry
instrumentation
rack
is
required
when
you,
when
you
require
the
rails
instrumentation
and
then,
if
we
scroll
down
the
configuration,
falls
kind
of
our
standard
pattern
that
we've
been
doing
looking
at
this
now.
I
think
that
we
should
probably
do
a
bit
of
a
version
check,
because
I
have
no
idea
if
this
works
with
stuff
earlier
than
five
two.
C
C
C
B
C
It
just
happens
earlier
in
the
initialization
life
cycle.
If
you
use
like
the
standard
rails,
config,
slash,
initializers
folder
and
you
put
initializer
in
there
it's
less
forgiving,
which
is
why
I
have
the
rail
test
setup
as
it
does,
but
in
terms
of
like
the
configuration
stuff,
I'm
not,
I
didn't
honestly
didn't
dig
super
deeply
into
it,
because
I
was
looking
at
it.
I
I
think
the
way
it
is
right
now
is
fine,
so
I
didn't
want
to
like
have
to
change
all
the
configurations
to
support
this.
D
Yeah,
it
looks
like
a
fallback.
Sorry,
it's
just
reading
through
the
the
order
that
things
are
done.
I
was
worried
that
we
had
an
implicit
dependency
on
the
order
of
rails
versus
rack
configuration
and
the
way
it's
done
here.
All
the
configuration
I
think
is
done
earlier
so
like
all
that,
if
somebody
explicitly
configured
the
rail,
the
rack
instrumentation
that
would
be
done
before
the
rail
tie
then
tries
to
do
the
instance.install.
D
C
Don't
know
if
we
should
add
handling
to
check
to
see
if
that
works
already
installed
or
not.
Maybe.
B
Yeah
yeah
good
first
step,
I
feel
like
I
feel
like
it
can
be,
I
feel
like
rails-
has
its
view
of
the
middleware
stack
and
then
there's
the
actual
middleware
sack
that
rack
sees
and
it's
hard
to
it's
hard
to
get
access
to
that.
I
think
from
from
rails.
If
I
recall
so,
it
might
be
more
work
than
it's
worth.
C
A
A
But
I
think
it's
less
horrible.
I
hope
it's
crashing
was
difficult.
There's
a
lot
of
stuff
that
gets
cached.
If
I
recall
correctly
that's
hard
to
clear
out.
C
Yeah,
so
this
is
kind
of
the
premise
that
I
took.
The
commit
messages
are
a
lot
more
verbose
of
my
misery
if
you're
interested,
but
the
idea
is
the
test.
Helper
will
start
by
setting
up
this
default
rails
app
and
it's
just
the
global
one
for
all
tests
that
we'll
need
to
test
this
rails
app
and
for
all
intents
and
purposes,
that's
the
one
you
use
you
don't
care,
you
say
default
rails
app
and
we
set
colon
colonrails.application
to
be
the
default
rails
app.
C
You
don't
actually
need
to
do
that
because
the
ordering
should
do
that
by
default,
but
I
want
it
to
be
very,
very
explicit,
because
you
can
only
have
one
and
it
gets
weird
if
you
rely
on
rails.application
and
someone
changes
it
in
the
test.
Basically,
you'd
have
flaky
tests,
so
we
do
all
the
setup.
We
do
the
configuration
we
do,
the
install
we
initialized
the
app.
So
then,
if
you
go
down
to
app
config,
this
is
the
fun
part
that
I
fought
with
in
app
config.
C
Essentially,
it
sets
it
up
to
support
controller
actions
and
nothing
else
right
now,
I'm
hoping
that
I
haven't
missed
anything
when
we
decide
to
add
active
record
and
friends,
but
the
order
in
initialize
app
is
really
really
specific
and
the
initialize
for
the
bang
call
does
leak
state
what
I
learned
later
on.
So
I
think
that's
what
you're
talking
about
with
the
weird
caching
and
trying
to
clear
that
out
when
you
initially
initialize
a
rails,
app
initializing,
a
second
rails,
app
behaves
differently
than
the
first
one
yep.
C
C
C
A
Yeah
I
mean,
I
think,
with
tess
it's
like.
If
you
get
something
that
works,
it
doesn't
have
to
be
beautiful
and
that's
like
not
the
point
of
test.
You
know
factories
and
specs.
It's
like
it
just
needs
to
work.
So
this
looks
good.
I
can
definitely.
I
know
I've
been
like
way
beyond
reviews,
but
this
is
in
a
really
good
place.
C
Yeah,
I
don't
know
like
I'm,
not
sure
if
there's
anything
else,
that's
really
interesting.
There's
just
a
couple
test
controllers,
some
middlewares
and
stuff
that
we
just
added
quickly
test
different
scenarios.
I
tried
to
think
of
the
ones
that
I
was
familiar
with
from
shopify's
app
and
problems
we
were
dealing
with
and
just
making
sure
that
we
can
easily
test
the
behavior
in
those
situations
like
what
happens
when
it
redirects
in
a
middleware.
What
happens
when
the
middleware
race
is
an
exception?
What
happens
in
controller
race
is
an
exception
stuff
like
that.
B
This
looks
pretty
clean,
like
I
think
the
the
amount
of
things
here
does
not
at
all
represent
the
amount
of
work
that
went
into
making
that
look
so
nice.
B
So
I
recognized
that
this
yeah,
that
that
was
that
was
a
ton
of
work,
but
it
looks
like
it
was
very
skillfully
done
so.
C
Yeah,
like
I
said,
if
you
want
to
see
the
true
misery,
read
the
commit
messages,
nothing
offensive,
but
just
like,
I
feel,
like
the
frustration
emanates
from
it,
because
it's
like
do
it,
do
it
again,
but
with
more
words,
yeah
yeah.
C
So
I
I
think
this
is
probably
a
good
point
for
a
v1
and
then
I'm
sure
there's
going
to
be
requests
to
change
additional
things,
and
I
think
that's
great,
and
I
expect
that
and
I'm
just
hoping
that
this
sets
us
up
in
a
place
where,
whether
it's
me
or
someone
else
has
this
healthy
foundation.
To
like.
I
want
to
add
a
test
for
this
and
some
behavior
around
that
nobody
has
to
kind
of
go
through
this
whole
song
and
dance
of
getting
a
rails
app
to
initialize
for
their
scenario.
B
B
Yeah,
thank
you
for
walking
us
through
this,
like.
I
think
that
answered
a
lot
of
questions
that
I
probably
would
have
had
if
I
was
looking
through
it
myself.
The
one
question
that
I
have
that
we
didn't
cover
is
just
like.
We
talked
about
whether
or
not
active
support
notifications
would
be
an
approach
for
this.
B
Ultimately,
it
seems
like
since
really
the
name
of
the
game
is
just
renaming
this
rackspan,
that's
probably
overkill.
Was
that
kind
of
the
the
general
consensus
there
or
were
there
other
thoughts
that
went
into
that.
A
I
think
from
I
spoke,
my
colleague
dave
elner
who's,
a
lot
more
experienced
than
me
and
wrote
a
lot
of
the
a
lot
of
this
code.
However,
many
years
back
at
datadog
said
that
their
decision
at
the
time
was
based
on
active
support.
Notifications,
not
tracking
any
hooks
associated
with
the
controller,
are
not
part
of
the
timing
of
the
active
support
notification
like
before.
B
A
Yeah
the
action
hooks,
which
are
arguably
an
anti-pattern
but
are
very
common
and
people-
you
know
they're
first-class
citizen
and
that
so
that
was
one.
I
think
that
was
the
main
thing
they
meant
he
mentioned
was
their
thought
process
there.
But
you
know
you,
you
probably
have
just
as
much
experience
here.
That
was
the
only
feedback
I
got.
C
Yeah,
I
I
never.
I
I've
actually
not
spent
any
real
time
with
active
notifications,
but
from
the
comments
that
were
left.
It
was
kind
of
like
maybe
active
notifications,
but
maybe
not
and
like
one
of
your
comments
that
I
was
probably
just
gonna
repeat
was
just
it
seems
like
the
more
robust
approach
here
for
monkey
patching
metal
and
to
me.
I
think
I
guess,
when
I
was
working
on
this
it
it
just
seemed
so
simple,
like
monkey
patching
metal
unless
I'm
missing
something
very
grand.
It's
just.
C
It
just
seems
like
such
a
simple
change
that
pursuing
anything
else.
Didn't
I
don't
know
it
didn't
seem
like
a
starter
for
me.
I
think
france
left
some
comments
too,
suggesting
that,
like
he
was
leaning
more
towards
patching
the
action
controller,
metal.
D
Yeah,
although
my
comments
there
were
based
on
the
assumption
that
you're
actually
going
to
be
tracing
so
creating
a
span
around
the
action,
controller,
metals
or
using
active
support
notifications
since
you're,
not
you
could
arguably
use
asm
because
you're,
just
hammering
in
the
span
name.
D
C
B
I
don't
see
any
like
clear
winners
between
the
approaches,
and
I
think
time
will
tell
if
this
is
gonna
like
hold
up
for
for
everybody
and,
as
we
start
to
like
get
some
active
support
notification
based
instrumentation,
I'm
assuming
we
will
at
some
point
like
active
record.
I
would
imagine
you
would
want
to
use
this
and
kind
of
build
out
our
toolkit
or
for
active
support.
C
C
I
know
we're
running
short
on
time.
Like
I
mentioned
that
I
wanted
to
talk
a
little
bit
about
the
graphql
pr.
I
can
leave
it
as
like
a
comment,
but
the
two
second
version
of
it
is
just
some
of
the
things
that
are
right
now,
as
the
pr
stands
being
traced
by
default,
I
think
we
should
add
configuration
to
shut
them
off
because
they're
way
too
noisy.
A
Yeah
this
was,
I
think,
it's
a
really
interesting
like
philosophical
question,
because
it
just
can
be
a
performance
killer
and
but
the
trade-off
being
like
you
know,
out
of
the
box
up
and
running,
you
know
we're
a
vendor
which
we're
not
so
yeah.
I
I
tend
to
agree.
I
don't
know
enough,
I
don't
use.
A
If
there
are
ones
you
know
are
problematic.
Definitely
I
would
I'm
100
on
board
with
like
having
a
more
restrictive
default
list
and
then
exposing
a
configuration
option
saying
like
passing
whatever
you
want
to
you
know
I
I
there
might
have
been
some
discussion
on
the
on
the
pr
about
it.
A
Oh
oh
you're,
saying
about
the
not
about
schemas
you're,
saying
about
like
all
the
actions
that
we
instrument.
D
Yeah
yeah,
but
robert
showed
me
a
simple
case
or
a
simple
example
in
one
of
our
apps
today,
where,
without
it
we
had
11
graphql
spans
with
it.
We
had
two
and
a
half
thousand
or
over
two
and
a
half
thousand
okay.
A
A
Do
you
want
all
the
middleware
junk,
but
I
think
maybe
just
pulling
yeah,
if
you,
if
you,
if
you
don't
mind
commenting
on
the
ones,
you
know,
are
problematic
or
just
too
noisy,
I
think
we
could
just
have
a
default
list
that
people
could
add
additional
keys
or
strings
to
that
they
want
okay,
cool
and
I
do
have
to
I
know
I
have
to
finish
this
up.
I've
just
been.
A
C
It's
not
necessarily
part
of
this
pr,
but
something
that
I
think
I'll
want
to
try
to
pursue
later
on.
At
some
point
is
like
these.
These
fields
are
really
noisy,
but
I
think,
like
the
specifically
the
execute
field,
one
it
that
went
from
11
spans
to
2500,
there's
a
lot
of
really
useful
information
that
gets
lost
when
you
lose
them
or
potentially
useful,
because
executing
one
field
might
take
a
second
and
another
might
take.
C
C
So
maybe
supporting
the
ability
to
conditionally
trace
that,
like
say,
like
someone
wants
to
do
a
specific
test
against
production
passes
in
some
sort
of
like
query
parameter.
That
says
like
somehow.
I
don't
know
how
that
would
look,
but
like
yeah
on
the.
A
D
D
So
if
you've
got
like
a
bunch
of
spans
that
look
very
similar,
they'll
roll
them
up
into
a
single
aggregate
span
with
information
about
like
the
distribution
of
times
or
you
know,
there
were
five
spans
with
this
tag
and
two
and
a
half
thousand
with
this
other
tag
right
so
being
able
to
ex
like,
depending
on
your
trace
back
end,
you
may
want
to
have
more
verbosity
than
than
you
would
by
default.
D
A
Yeah,
I
think
that
makes
sense
cool,
okay.
I
can
make
sure
to
get
this.
I
can.
I
can
iterate
on
this
in
the
coming
days
or
at
minimum
over
the
weekend,
but
cool,
that's
good
feedback.
I
definitely
won't
mind
if
we're,
since
we
only
have
like
a
minute
here.
If
anyone
has,
I
tried
to
give
reviews
to
the
and
delayed
job
inter
into
instrumentations.
A
I
think
they're.
Fine.
A
There
was
a
little
bit
of
a
back
and
forth
on
delayed
job,
and
I
was
a
little
confused
on
whether
I
have
a
concern
on
there
and
you
can
read
the
comments
that,
if
a
process
exits
or
if
we
have
a
tr
spans
and
a
buffer
in
like
a
batch,
that
we
would
lose
those
spans,
but
it
seemed
the
contributor
seemed
to
think
it
wasn't.
The
case.
D
It
is
so
we
have
the
ability
to
shut
down,
so
somebody
could
somebody
can
explicitly
shut
down
tracing
which
will
have
the
effect
of
flushing
the
spans,
and
arguably
they
should
be
trying
to
do
that
as
part
of
their
application.
Life
cycle.
D
So
we
we
do
that
for
our
internal
tracing
gem,
but
you
may
also
want
to
handle
signals
as
well.
So
if
you
have
kind
of
an
abrupt
termination,
you
may
want
to
have
some
chance
to
to
flush
something.
D
So
that
is
what
we
do.
I
think
you
need
some
flexibility.
I
sometimes
add
exit
is
too
late
and
some
application
servers
give
you
lifecycle
hooks
that
trigger
a
little
bit
earlier,
because
one
of
the
things
is
like
by
the
time
ad
exit
rolls
around.
You.
D
Don't
really
want
to
be
delaying
shutdown
for
too
long,
but
we
may
end
up
having
a
default
of
like
our
export
timeout
by
default
is
about
30
seconds
or
something
so
holding
the
application
for
holding
the
process
for
30
seconds,
while
you're
trying
to
flush
spans
may
be
excessive
and
may
not
be
a
great
out
of
box
experience.
D
B
It
seems
like
the
discussion
should
have
at
some
point
how
to
smoothly
make
sure
that
your
spans
leave
the
process
before
it
exits.
Somehow.
A
All
right,
sorry
for
sorry
for
forcing
you
guys
over
time
that
that's
helpful
and
yeah,
I
think
some
sort
of
addict
or
something
is
useful.
A
I
have
dinner
so
I'll
see
you
all
take
care.