►
Description
In this pair programming session we discuss the existing methods for calculating feature_category from Rails controllers and how we might extend this to receive the feature_category from the request header.
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67800
A
A
A
Another
question
is:
when
we've
had
this
discussion
before
with
doing
client-side
based
metrics
for
graphql,
is
it
possible
to
check
like
our
authentication
method?
Are
we
using
the
csrf
token
like
if
we're
using
the
csrf
token?
We
know
this
is
likely
coming
from
our
page,
as
opposed
to
someone's
someone's
crafting
a
request
manually
or
something,
and
so
maybe
we
want
to
check
that
as
well.
What
are
your
thoughts
on
that
of
like
we're
receiving
something
from
the
client
we're
going
to
overwrite?
A
B
C
D
D
I
don't
know
much
requests
or
something
like
that,
but
they
are
not
at
least
faking
new
ones,
which
could
become
a
problem
when
when
it
comes
to
metrics
and
when
it
comes
to
to
to
cardinality
of
metrics,
because
they
are
increasing
in
that
that
way,
so
they
could
just
spam
our
prometers,
that's
a
good
point
just
severe,
so
we
should
at
least
check
or
validate
the
input.
Nonetheless,
okay,
so.
B
E
Can't
be
it's
just
like
an
api,
that's
kind
of
what
I
was
gonna
mention
when
you
said
about
csrf.
That's
that's
interesting,
but
obviously
I
don't
know
what
one
I
would
say
is
primarily
if
it's
primarily
hit
by
the
git
lab
site
itself
or
5050,
or
that's
a
really
interesting
metric.
I'd
love
to
love
to
know
how
many
of
the
requests
are
coming
from
the
gitlab
website
versus
external.
But
you
know
as
it's
an
api.
E
I
almost
think
that
the
primary
usage
of
it
would
be
outside
yeah,
but
that
doesn't
mean
to
say
that
you
could
have
almost
like
an
optional
csrf
type,
tokeny
thingamybob.
The
other
thing
that
I've
seen.
I
don't
know
whether
we
we're
gonna
run
a
mile
when
we
hear
this,
but
is
a
sort
of
what
we
call
it
almost
like
security
for
obfuscation.
E
So
if
we
were
to
use
a
code
of
some
sort
rather
than
an
english,
do
you
know
what
I
mean
so
the
header,
I'm
not
gonna,
say
it's
encrypted
in
any
sort
of
way.
But
you
know,
I
just
see
you
thinking
what
what
are
people
going
to
try,
what
what
they're
going
to
be
looking
to
achieve
by
maliciously,
manipulating
this
and
yeah
and.
A
C
C
One
other
issue,
though
graphql
is,
is
the
biz
that
can
interact
with
a
lot
of
categories
within
the
same
request
like
you
can
pull
the
data
from
groups,
issues
manage
requests
whatever
you
want
else
within
a
single
measure
within
a
single
request,
so
you
cannot
say
even
even
so
you
cannot
say
well.
This
is
a
like,
but
in
rest
api.
You
know
that
if
you're
accessing
projects
or
issues-
that's
a
certain
category
right,
you
can,
you
can
bind
it
somewhat
to
to
the
api,
whereas
in
graphql
you
cannot
really
do.
A
C
A
Now
and
that's
that's
a
really
great
point
too,
and
this
is
kind
of
a
trade-off-
we've
decided
to
iteratively
accept
right
now,
we're
still
in
parallel
to
all
this
working
on
getting
traceability,
to
feature
categories
and
stuff
from
the
backend
from
the
actual
resolvers
and
the
fields,
but
right
now
it's
just
every
graphql
thing
goes
in
one
bucket
and
so
we're
trying
to
trying
to
just
start
on
splitting
it
up
and
splitting
it
up
from
and
here's
the
downside
too.
We
would
be
splitting
it
up
from
what
is
the
feature
category
of
the
page.
E
That's
that's
interesting
because
that
was
going
to
be
my
sort
of
response
prior
to
your
response
was
saying:
well,
no,
we're
not
interested
in
what
is
they're
trying
to
consume
it's
where,
where
they're
consuming
from,
but
is
that
what's
the
word
I'm
looking
for?
Is
that
you're
just
doing
that
because
that's
the
best
you
can
do.
That's
not
what
you
actually
want
to
do.
It's.
A
A
A
Well,
I'm
always
testing
you
guys.
I
I
think
this
is
I
I
do
agree.
This
puts
us
at
maybe
some
sort
of
net
positive
and
in
no
way
is
it
slowing
down
the
work
we
need
to
do
on
the
back
end,
it's
just
kind
of
have
something
that
we're
going
to
try
out
in
parallel.
So
this
is
still
I
still
say.
This
is
a
bit
experimental
to
see
and
I
think
the
concerns
are
valid
and
the
concerns
are
kind
of
mentioned
and
shared
of
getting
this
information
from
the
client
side.
B
A
B
A
And
we
do
that's
actually
exactly
what's
happening,
so
you
can
actually
go
to
any
git
lab
page
and
I
think
it's
inside
of
our
lovely
gone
feature.
Category
yeah,
just
like
we
did
that
with
feature
flags
gone
feature,
is
the
features.
Okay,
I
haven't
get
labbed
in
a
while,
just
like
we
get
the
all
these
from
the
back
end.
This
is
this
is
what
the
value
we're,
injecting
into
our
request
from
our
graphql
apollo
client.
That's
what
we'll
be
setting
in
some
sort
of
header
is
this.
This
value.
A
C
E
A
E
B
A
E
A
A
E
All
we
need
to
do
instead
of
calling
it
as
we're
doing
there
we
do
a
before.
Can
you
hop
back
to
the
contract
again,
someone
I'm
sure
someone
will
tell
me
if
I'm
wrong
here.
So
instead
we
do
like
a
before
action
and
tell
it
to
call
something
like
set
set
feat
feature
category,
and
then
we
create
a
yeah
yeah.
Exactly
then
we
create
that
method
in.
E
C
D
D
Yeah
this
one,
this
is
all
the
two
methods
are
actually
class
methods,
and
so,
if
you
look
and
what
we
want
to
do
is
actually
to
to
determine
the
feature
category
based
on
the
action
which
is
on
the
instance
level,
not
on
the
class
level.
So
if
you
look
into
the
application
controller,
you
can
find
a
method
which
is
named
feature
category.
D
The
application
controller
is
the
base
controller
for
all
for
all
of
them.
So
if
you
look
for
feature
category
next
one
it's
actually
it
is
calling
the
class
method
for
that.
So
what
we
could
do,
I'm
not
sure
if
it's
the
most
not
hacky
approach
would
be
to
override
this
feature.
Category
method
in
the
graphql
controller
and
roll
our
own.
So.
A
Wow,
okay:
this
is
a
little
concerning
because
from
here
we're
looking
at
this
one
directly,
so
this
is
the
one
this
is.
This
is
what
I
had
manually
like
just
injected
this
one,
I'm
really
really
interested
in,
because
this
is
what
writes
to
the
prometheus
metric
and
we're
looking
for
feature
category
for
action
directly,
and
I
don't
know
if
overwriting
this,
the
graphql
controller
will
work.
Then.
D
A
A
A
B
I
don't
know
what's
happening.
I
like
I
thought
those
classmates
those
classmates
class
class
methods,
work
like
the
attributes
and
like
the
sidekick
workers
they're,
like
worker
attributes,
where
they
we've
used,
something
in
elastic
search
as
well
to
like
do
something
very
similar
where
you
have
this
method.
That
looks
like
it's
just
called
at
the
top
of
the
file
that
gives
properties
to
whatever.
C
D
B
D
D
A
Yeah,
okay
got
it,
and
so
these
are
totally
different
methods.
This
one's
able
to
access
self
all
that
stuff.
This
one
would
not
be
able
to
got
it.
That
makes
sense.
Okay,
but
be
it
does
look
like
we.
This
might
is
the
target
of
something
that
we
want
to
have
the
behavior
change,
because
that
class
level
method
is
is
kind
of
what
we're
targeting
over
here.
I
guess
and
so
changing
the
instance
level
method.
Unfortunately,
I
don't
know
if
that's
going
to
work.
D
A
D
C
A
D
D
For
the
class
instance,
okay,
I'm
sorry
for
confusing,
but
a
class
also
has
an
inset.
So
every
time
you
would
do
it
on
a
per
request
level,
you
would
change
the
class
configuration
yeah.
In
this
case
we
would
be
very
likely
adding
new
actions
and
validate
config
at
some
point
would
validate
governor.
Maybe
it's
it's
fine.
As
long
as
we
don't
pass
any
action
action
lists,
you
can
also
also
pass
a
list
of
actions
and
invalidate
config.
You
can
see
we
actually
validate
some
kind
of
okay,
a
little
bit
of
the
configuration
so.
D
Yes,
that's
true,
I
is
in
slack
I
suggested,
maybe
to
use
config
feature
categories.yaml,
which
we
already
have.
I'm
not
sure
why
we
are
not
using
this
yaml
to
check
the
or
to
validate
the
category
name.
Maybe
there's
a
reason
I
don't
know,
but
we
could
use
it
actually
to
to
check
it
like
for
all
feature
category
categories.
We
are
defining
yeah.
I
I
know
there's
a
the
last
issue
or
the
last
match
request.
I
I've
seen
to
update
this
yaml
file.
D
A
A
A
Maybe
we
need
to
have
a
way
that
we
can
expose
some
sort
of
class
method
here
to
do
like,
like
read,
feature
like
feature
category
from
request
or
something
like
that
and
then
somehow
that
we
can
write
something
like
that
too.
Oh
gosh,
this
is
just
an
array
of
this-
is
a
hash
of
a
raise.
I
don't
know.
E
So
I
think
I
think,
but
someone
I'm
sure,
step
in
and
say
which,
if
both
of
these
are
invalid
or
one
of
these
invalid,
but
we
could
either
override
that
feature
category
for
action,
method
inside
the
graphql
controller
or
inside
the
feature
category
fraction
method.
In
here
we
could
call
a
method
which
exists
in
the
graphql
controller
and
say
if
this
method
is
defined,
then
use
it.
A
A
E
A
E
E
A
Yes,
that's.
That
was
the
feedback
that
I
got,
which
makes
sense,
because
I
think
we
may
also
do
like
some
just
file
logging
using
this
and
if
we
just
update
it
just
for
prometheus,
it's
not
gonna,
we're
not
gonna,
see
it
in
other
places.
So,
but
we
do
want
to
just
update
it.
I
think
just
for
graphql
controller.
So
that's
that's
the
one
of
the
key
key
things
here.
A
B
C
A
A
And
even
if
I'm
setting
it
here
like,
how
am
I
going
to
get
the
requests?
Because
that's
and
that's
needs
to
be
at
the
instance
level-
these
are
all
class
mobile
methods
so
over
here
in
web
transaction.
When
I
call
this,
this
is
just
a
weird
part
of
how
these,
like
transaction
things,
work.
All
of
the
information
you
want
actually
lives
in
this,
like
environment
variable,
even
headers
and
stuff
just
all
lives
in
this
glorious
hash.
C
A
D
B
A
B
A
And
I
think
that's
why
all
this
is
at
the
class
level
is
because
we're
kind
of
like
oh
something
came
from
something
this
this
controller
by
name.
What's
the
feature
category
for
that
controller,
and
but
I
do
think
from
this
level
we
we
do
have
I'm
pretty
sure
we
have
requests
and
if
not
we
we
should.
The
request
object.
D
B
C
A
D
If
we,
we
might
need
to
make
feature
category
instance,
method,
public
or
just
use,
send
on
the
instance
of
the
controller,
but
I'm
not
sure
if
it's
the
best
approach,
I'm
trying
to
understand
why
we
are
not
just
using
application
context
for
it,
because
we
have
gitlab
application
context,
which
is
we
are
in
this
one.
We
are,
I
think,
storing
a
bunch
of
attributes.
C
D
A
Well,
yeah:
this
is
a
great
point
and
I
think,
making
feature
category
public
is
makes
so
much
sense,
because
I'm
here
outside
of
the
instance
trying
to
call
the
method,
it
would
be
nice
if
the
method
was
public.
I
don't
know
how
great
we
feel
about
you
know
adding
to
application
controllers
public
interface,
because
this
is
you
know
the
god
controller.
C
D
A
C
C
D
C
D
D
Yes,
we
could.
We
also
want
maybe
to
do
like
a
try
as
before,
because
of
the
same
reason.
So
it
could
be
that
the
controller
is
not
not
an
application
controller
yeah,
so
just
remove
class
yeah
this
one
and
so
try
is
like
a
rails
method.
I
think
which,
which
tries
to
call
a
method
on
an
object
and
if
it
doesn't
isn't
defined,
it
doesn't
race,
as
we
usually
do
in
ruby,
but
it
just
returns
nearly
as
far
as
I
understand.
Okay,.
E
E
I
almost
think
well
do
we
want
to
I'd
almost.
Rather
we
had
our
own
method
that
we
don't
have
to
worry
about
there
being
another
method
with
that
name,
that's
gonna
kind
of
screw
us.
If
that
makes
it
you
see.
What
I
mean
like
is
the
the
current
feature,
category
definition
going
to
return
the
same
thing
as
feature
category
for
action.
A
D
D
D
C
C
B
A
I
don't
think
I
do.
No,
that
is
interesting
and
yeah.
That's
a
good
question
and
it
looks
like
sean
is
already
involved
here,
so
I
will
be
able
to
ask
him
that
question
too
and
I'll
make
a
note
of
that.
Well,
this
has
been
wildly
helpful
and
I
will
ping
you
all
thanks
for
pairing
when
I
push
up
a
commit
for
this,
but
yeah
thanks
thanks
so
much
for
your
help
on
this
and
talking
the
problem
out,
I
feel
better
about
not
adding
something.