►
Description
Related MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/129075
This MR’s pipeline is failing because an existing N+1 test now fails because the query count has gone up.
Looks like someone else brought up a different N+1 issue in an MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/126175
Related issue about general N+1 testing guidance: https://gitlab.com/gitlab-org/gitlab/-/issues/385205
Documentation on Query Recorder:
https://docs.gitlab.com/ee/development/database/query_recorder.html
Gem that detects N+1 issues: https://github.com/charkost/prosopite
A
B
A
Okay,
okay,
well,
we'll
see,
I
mean
I
think
this
is
this
feels
like
an
evergreen
topic
to
me
because
it
keeps
coming
up,
and
actually
this
came
up
when
I
first
joined
gitlab,
one
of
my
first
Mrs
lucky
knee
had
an
N
plus
one
failure.
It
had
several
one
plus
one
failures
and
I
just
found
the
whole
process
of
understanding
where
it
was
coming
from
how
to
fix
it
to
be
very
confusing
and,
as
it
turns
out
today,
I
had
an
N
plus
one
error
and
it
still
found
it
really
confusing.
B
A
A
Okay,
so
and
I
like
this
Mr
in
particular,
it's
a
refactor,
maybe
I,
want
to
go
through
with
it.
I
just
thought.
I
also
noticed
that
somebody
brought
up
in
the
back
end
Parish
Channel
yesterday,
another
Mr
with
an
N
plus
one
issue,
and
so
I
was
like.
Oh,
this
is
a
good
topic
because
I
I
find
it
overwhelming,
like
you
already
said,
and
it's
tough
so
the
issue.
First
of
all,
let's
look
at
our
documentation
on
how
to
resolve
an
N
plus
one,
because
that
was
the
first
thing
that
I
did
today.
A
Are
here's
our
documentation
how
to
use
Query
recorder
to
detect
an
N
plus
one
query
problem,
and
so-
and
there
is
some
debate
about
like
whether
we
should
do
a
control
query.
We
can
talk
about
that
as
well,
so
it
records
number
of
queries
and
you
basically
say
like
create
a
new
object
and
then
expect
a
new
load
of
the
page
to
have
the
same
number
of
queries
as
the
old
one,
no
n,
plus
one.
A
It's
in
a
graphql
test:
why
are
you
not
opening
for
me?
There
we
are
here.
We
are
I
thought
it
was
gonna,
be
in
the
theater
here
so
in
ee.
It
says
shared
example,
so
it's
this
fun
syntax
and
it's
failing
all
three
of
them
are
failing,
so
the
control
count
and
bump
us
up
a
little
bit.
The
control
count
is
14.
A
just
from
a
few
small
changes
here.
So
let
me
open
this
up
and
just
close
this,
not
too
small.
So
let's
find
an
instance
of
this
and
kind
of
look
at
it,
because
the
first
thing
that
I
tried
to
do
was
log.
What
it's
actually
like
I
was
kind
of
like
well.
What
is
the
actual
query?
That's
happening
right,
and
so
that's
this
finding
the
source
of
the
query.
B
A
A
A
A
B
A
B
A
B
A
B
Usually
well,
I
normally
have
like
a
slight
idea
which
queries
it'll
be
so
I'll
just
start
looking
for
one
of
those
callback,
those
back
Trace
blocks
and
then
look
at
the
query
and
see
if
that
one
is
the
one
that
applies
and
then
usually
the
first
few
lines
of
the
back.
Trace
will
tell
me
if
I'm
right
or
not
so
that's
usually
how
I
go
about
them.
C
A
Okay,
yeah,
because
I
actually
I
did
notice
that
there
was
a
flaky
test
today
related
to
an
N
plus
one
and
I
noticed
that
the
person
debugging
it
like
very
cleanly
listed.
All
of
the
queries
that
were
run
into
in
order
to
debug
it
I
would
show
it
here,
but
it's
on
a
security
change,
so
maybe
I
shouldn't.
B
A
A
A
The
change
that
I
made
here
is
that
I
moved
around
some
policy
stuff,
and
so
this
is
checking
for
a
weather.
An
attribute
is
set
on
a
project
and
I
think
what
happened
is
because
of
the
way
I
shuffled
things
around.
That
feature
is
like
being
checked
now
when
it
wasn't
previously
because
of
the
way
policies.
Work
right,
like
the
policies
were
run
in
certain
orders,
depending
on
a
variety
of
factors
and
I.
A
Think,
because
of
the
way
I
refactored
it
that
this
is
now
being
checked
when
it
wasn't
before
so
security
and
compliance
disabled
is
actually
looking
for
whether
the
security
and
compliance
attribute
is
set
to
disabled
on
the
project
so
I.
If
I
were
to
go
for
Sam's
approach.
I
would
just
look
for
security
and
compliance,
because
that's
the
attribute,
but
I
don't
see
that
coming
up.
A
C
A
A
as
of
this
change,
so
whatever
I
did
in
this
policy,
the
number
of
queries
that
are
now
run
for
a
single
record
is
17.,
so
I
could
just
change.
This
hard-coded
query
account,
but
then,
even
when
I
change
that
to
17
the
multiple
query
counts
are
also
wrong
now,
because
they
have
three
more
so
that
and
to
me
indicates
that
there
is
an
N
plus
one,
although
I
truly
don't
understand
what
three
times
three
means
here,
like
the
definition
of
a
magic
number
like
why?
Why.
B
A
B
A
A
I
think
that's
probably
right.
I
I
put
a
before
and
after
in
in
the
Mr
description
here
and
you'll
notice
that
this
is
before
and
it
does
the
for
this
endpoint.
By
the
way.
The
policy
that
is
checked
is
is
read
vulnerability,
so
you
only
need
to
worry
about
revulnerability
right
now,
so
read
vulnerability
is
checked
before
we
were
like.
Can
you
both
read
security
resource
and
a
security
compliance
disabled?
It
may
very
well
be
in
this
test
file
yeah.
This
user
is
not
it's
just
usually
even
a
member
of
the
project.
A
Oh
ad
developer,
okay,
so
they
are
being
added
as
developers,
so
they
should
be
able
to
see
things
here,
I
think
and
so
and
then
the
next
rule
is,
but
he
sorry
I'm
like
talking
about
myself.
This
is
where
declarative
policy
is
strange.
So
the
way
the
declarative
policy
works
is
that
at
least
one
enable
call
has
to
be
made
for
the
permission
to
be
enabled
and
no
prevents
right.
A
In
the
stack,
declarative
policy
is
going
to
go
through
and
look
at
each
of
those
prevents
until
it
hits
one
because
it
needs
to
know
like
because
at
least
one,
but
if
it's
all
enables
in
that
list
as
it
is
here,
it
only
needs
to
check
the
first
one
and
if
it
is
a
go,
if
it
says
thumbs
up
that
it
can
actually
not.
It
can
avoid
this.
B
A
And
by
the
way,
it
doesn't
always
run
in
this
order
like
this
is
not
the
cellular
order
of
evaluation.
It's
just
the
list
of
things
that
we
checked
so
in
the
after.
We
now
have
three,
and
one
of
them
is
prevent,
so
prevent
will
always
be
checked,
not
necessarily
first
but
potentially,
and
then
once
it's
gone
through
that,
then
it
might
check
one
of
these
other
ones.
C
A
A
A
A
C
A
C
C
System
doesn't
feel
great,
like
the
in
terms
of
what
we
have
in
place
here
to
protect
us
against
n
plus
ones.
I
feel
like.
If
we
get
an
error
like
this,
we
want
to
be
able
to
immediately
see
what
the
problem
is.
Like
you
know,
in
more
like
an
aspect,
diff
kind
of
expected.
This
got
this.
You
know
yeah
and
I've,
seen
I've
seen
the
query
recorder
implemented
in
a
few
places
in
a
different
way
where
people
are
like.
C
C
A
A
A
B
C
B
C
B
A
B
C
B
A
A
C
A
C
B
B
B
B
A
Like
this
is
using
safe
request,
loader,
so
in
theory,
like
our
n
plus,
one
test
could
benefit
from
request
store
right,
because
that's
why
the
whole
point
of
view
safe
request
loader,
is
to
in
the
context
of
a
single
request
to
cash
those
requests.
Even
if
this
is
made
multiple
times
for
the
same
user
and
a
request,
it
should
just
be
cash
and
not
be
run
again.
B
A
B
A
B
A
A
A
A
B
A
A
C
A
B
A
B
A
I
am
but
I
have
experienced
the
flaky,
the
flaky
n
plus
one
test
as
well,
because
there
are
certain
queries.
This
came
up
in
a
separate
issue
that
I
linked
to
in
our
agenda
that
there
are
some
queries
that
run
like
once
in
a
while,
and
so
there
are
a
lot
of
ways
also
to
write
n,
plus
one
tests
that
pass
when
they're
still
in
N,
plus
one
great
wow.
A
A
A
Okay,
avoid
false
positives.
Oh
this
says
use
a
different
user
for
each
request.
So
that's
another
tip
that
I
recently
became
aware
of
for
how
to
have
like
you're
doing
a
if
you're,
using
a
different
user.
Then
you
don't
need
the
warm-up
because
they're
both
like
first
requests
or
first
they're
gonna
like.
B
A
A
A
C
A
A
A
A
C
C
C
A
C
A
That
would
be
great
yeah,
I
think
I
mean
I
think
in
the
short
term.
One
thing
that
would
be
helpful,
I
mean
I
love
the
idea
of
automating
it
and
I
think
that's
what
we
need.
I
also
feel
like
our
documentation
here.
I
have
made
like
the
reason
I
I
had
that
issue
handy
about
query
recorder
and
and
how
to
think
about
this,
whether
you
make
three
requests
or
you
make
two
requests
with
different
users,
or
should
you
count
cash
queries
or
not?
A
A
B
A
B
A
C
B
C
B
B
A
B
A
A
B
A
A
C
C
C
A
B
A
A
A
C
A
C
Okay,
which
yeah
wow
quite
the
claims,
yeah
yeah,
that
is
quite
decline.
This
was
a
in-person,
ruby,
Meetup
in
town.
That
I
saw
this
talk
and
there
were
quite
a
number
of
people
in
the
audience
who
said
yeah
that
gem
is
great,
so
really
yep,
certainly
like
people
who
didn't
like
bullet
like
this,
but
I
feel
like
anything
like
this
is,
is
probably
we're
asking
too
much
to
just
drop
into
gitlab.
A
C
C
A
C
A
A
C
B
B
B
A
A
B
A
A
C
B
A
B
C
B
C
B
C
A
C
A
C
B
A
B
B
There's
there's
only
do
it
live
and,
if
not
feature
flag
at
least
life
yeah
yeah,
some
things,
that's
the
the
hardest
part
about
the
database
performance.
You're
always
like
in
this
nebulous
cloud
of
you're
testing
this
on
a
proxy,
but
you
don't
know
how
actual
live
will
handle
it.
Yeah,
there's
more
performance
versus
more
rows.