►
Description
**Result:**
- https://gitlab.com/gitlab-org/gitlab/-/merge_requests/31481
- https://gitlab.com/gitlab-org/gitlab/-/issues/217140
**Highlights:**
- 1:38 Where does this 5000ms timeout come from?
- 6:00 Start running the spec.
- 13:10 Considering if something like debounce is the issue, we review what debounce actually means.
- 16:00 Some discussion on integration vs. unit tests
- 25:50 Summarizing options discussed
- 29:10 What do we think of ad-hoc bumping the test timeout
- 30:30 We start slicing away to discover what's taking a long time
- 38:20 We start to see some improvement!
- 44:38 Summarizing the problem and approach again
- 45:30 We finalize our solution to fix the spec, but mounting lots of epics is still slow
- 49:00 We start exploring what parts of the component are slow
- 54:30 We talk about profiling in production as opposed to the test environment
- 57:57 We summarize some key takeaways
A
And
I
will
share
my
screen
about
the
issue
that
we're
looking
at
so
as
opposed
to
looking
at
just
a
justice
issue.
That's
thinking
it'd
be
helpful
to
solve
this
flaky
speck,
and
this
is
flaky
because
it
times
out
too
long-
and
you
see
here
that
we
have
a
time
of
five
seconds.
So
there's
a
lot
to
be
winned
here.
If
we
can
make
it,
you
know
less
than
a
second,
which
would
be
great,
and
maybe
we
can
figure
out
how
to
avoid
long.
A
B
A
This
is
a
really
good
question,
I'm,
not
entirely
sure
where
it
comes
from.
It's
probably
gonna
everything.
This
is
kind
of
like
your
entry
point
for
this
test
set
up
files
like
your
entry
point
for
just
setting
up
the
just
environment,
so
it
will
come
here.
Oh
here
we
go
and
it
looks
like
we
have.
This
helper
function,
initialize
test
timeout
and
then,
if
it's
CI,
you
see
it's
we're
gonna
wait
five
seconds
but
locally.
We
weighed
500
milliseconds
reasoning
behind
this
I
think.
A
Originally
we
had
it
at
500
milliseconds,
and
it
was
like
that
for
CI
and
local.
But
then
there
was
some
significant
flakiness
in
CI,
though
we
started
to
increase
it,
hoping
to
find
a
good
place
where
it
would
be
consistently
fail
at
it
show
when
there's
a
test,
that's
slow
when
we
need
to
make
it
faster,
but
I.
Think
anytime,
you
have.
You
know
some
sort
of
threshold
like
this
there's
there's
room
for
flakiness
because
we're
in
a
non
deterministic
environment
every
time
ci
runs
and
that's
that's
just
the
nature
of
it.
A
C
D
C
There's
a
problem,
for
example,
with
one
road
map.
It
was
related
by
me
and
I
also
like
to
point
with.
We
have
a
lot
of
time
out
in
our
specs
and
important
point
to
note
with,
because
we
were
on
all
our
tests
in
Bend,
so,
like
my
run
out,
is
in
parallel.
Some
of
them
can
fail
due
to
it.
So
we
should
keep
that
in
mind
and.
C
A
A
A
A
But
ya
know
just
is
really
fast
and
but
we
have
a
lot
that
are
you
know
the
whole
file
takes
about.
It
can
take
like
10
to
20
seconds
sometimes,
and
that's
we
we
haven't.
We
haven't
done
something
right
when
we're
doing
things
at
this
unit
test
level,
but
maybe
we're
we
have
we're
spinning
everything
up,
we're
doing
unit
tests,
we'll
focus
on
an
individual
unit.
But
then
we
spin
everything
up,
we're,
probably
not
testing
at
the
right
level,
I'm
all
for
doing
integration
tests,
but
let's
not
test
it.
A
A
A
A
A
A
A
But
what
we'll
do
is
we'll
notice?
Oh
well,
these
can
actually
be
shallow
mounted,
but
these
other
specs
actually
need
to
be
full
mounted.
So
sometimes
we
do
this
and
we
pass
in
this
rather
than
just
hard
coding,
Oh
create
component
Chalam
ounce
will
pass
in
a
based
on
what
level
of
testing
we
want.
We're
trying
to
migrate
specs
over
will
pass
in
either
a
full
mount
or
shall
amount
here.
B
D
A
A
A
C
D
Think
I
have
an
idea
like
I
know
for
sure
that
the
bounce
doesn't
work
ingest
and
if
this
function,
if
this
component
is
using
rebounds,
which
means
the
bounce
isn't
working
and
it's
the
squad
event
is
firing
very
rapidly
and
there's
a
lot
of
stuff
happening,
which
shouldn't
really
happen
in
the
normal
browser
environment,
so
yeah.
If
you
can
get
to
that,
maybe
they'll
get
to
the
conclusion
that
we
are
using
the
bounds
here.
So
that
will
solve
a
problem.
I.
A
Don't
see,
I
don't
see
the
balance
in
these
specs
and
something
that
we
did
do
recently
in
our
in
our
Jess
folder,
because
the
balance
was
causing
lots
of
issues
with
us
migrating
from
karma.
We
did
make
the
bounce
manually
mocked
for
all
specs
and
it
dist
now's.
It
just
calls
the
function
synchronously
so
that
ideally
shouldn't
be
causing
issues
because
it
was
causing
issues.
But
hopefully
it's
not.
What
were
you
saying?
Jackie?
What's.
A
A
This
one
is
like
I
could
I'll
keep
moving
it,
but
it's
just
gonna
space
them
out
every
200
milliseconds,
and
so
sometimes
you
want
to
do
the
throttle
for
user
input.
It's
usually
not
the
thing
you
want
to
do.
Usually
we
use
like
the
bounce
for
like
user
input
or
scrolling
like
because
the
user
wants
to
do
something
fluid
and
then
they'll
pause
for
a
second.
Then
we
do
our
thing,
that's
what
we
used
to
balance
for
yeah,
I'm
glad.
This
was
a
good
illustration.
There's
some
really
unhelpful
illustrations
out
there.
A
So,
but
as
you
can
see,
that
kind
of
asynchronous
behavior,
if
if
it
used
just
the
regular
like
timeouts,
it
wouldn't
cause
a
problem
with
Jess,
but
lo
dashes
implementation
of
debounce
actually
uses
like
requestanimationframe,
like
other
things
that
we
haven't
marked
in
Jess
and
just
causes
issues.
So
this
is
why,
when
we
were
working
on
moving
things
over,
we
always
ran
into
issues
with
the
bounce,
and
we
thought
okay,
so
it's
gonna
be
faster
if
we
just
mock
it
all
out,
but
we
we
have
some
improvements.
A
We
hopefully
want
to
do
with
that,
but
it
doesn't
seem
like
it's
necessarily.
They
shoot
here.
The
issue
at
hand
here
is
we're
doing
some
integration
testing
here
and
that's
a
good
thing.
I
like
integration
testing,
is
I
feel
like
it's
good,
but
it
seems
like
it's
slow.
What
are
you?
What
are
your
thoughts
on?
Okay,
let's
just
let's,
let's
now
create
you
know,
focus
unit
tests
on
it.
Do
you
feel
like
we're
losing
some
benefit
like
some
test
coverage?
A
Think
in
theory
we
should
we
we.
This
is
of
largely
on,
in
my
opinion,
I'd
love
to
know
fiddly
in
the
Mont
you
and
Jackie
your
experience.
This
is
largely
unexplored
area
and
our
good
lab
front-end
code
base
is
what
do
front-end
integration
tests.
Look
like
I
have
an
issue.
This
milestones
actually
to
do
one,
and
so
hopefully
we
can
have
an
example
to
work
off
of,
but.
B
A
That's
a
good
question,
I
kind
of
think
it
should
be
I
think
it
should
be
based
on
feature
I
think
we
should
then
have
integration,
because
it's
not
gonna
tie
back
to
a
unit.
It
would
be
we're
testing
this
front-end
feature
and
integration.
It's
gonna
be
really
we're.
Gonna
have
issues
like
this
on
our
test,
gonna
be
really
slow.
If,
for
every
unit
we
do
an
integration,
that's
an
antimatter.
A
If
I
do
an
integration
for
the
front
end
bundle
I'm,
gonna
get
all
of
my
integration
benefits,
but
now
I'm
testing
from
the
use
case
perspective
not
necessarily
from
my
unit
per
spekt
and
so
there's
a
little
bit
of
anti-pattern.
We
have
and
our
front
end
testing,
which
is
lots
and
lots
and
lots
and
lots
and
lots
of
unit
tests
and
then
feature
does
and
like
there's
this
huge
missing
area
in
our
testing
pyramid,
which
is
front-end
integration
test.
A
A
A
What
do
you
all
think?
Do
you
think
that
we
should
just
move
these?
Maybe
it's
a
different
spec
file
and
then
like
or
do
you
think
we
should
unit
to
five?
That
was
the
bells.
The
two
approaches,
I
think
is:
we
can
unit
to
Phi
this.
That
means
we're
gonna
have
to
add
we're
have
to
change
your
test
here,
and
it
looks
like
we're
missing
some
coverage
here
or
we
can
just
keep
this
integration.
D
A
A
B
A
Yeah
I'm
sad
to
be
losing
some
of
that,
but
you
also
look
at
this
and
you
see
okay,
we're
starting
against
and
we're
looking
at
component
internals
through
all
of
this.
So
maybe
maybe
there's
not
really
the
we
haven't
tested
at
the
right
level
either
like
who's,
not
really
looking
at
the
input
output
of
the
component.
D
A
A
A
A
B
A
A
F
A
F
A
A
A
Will
commit
this,
but
maybe
we
can
spend
some
time
either
tackling
another
test
or
if
we
want
to
unit
2
Phi
this.
What
do
you
think
of
it
early?
Do
you
feel
like
that's
a
good
solution
to
these
kind
of
when
we
have
slow
unit
tests
that
are
doing
more
integration
stuff?
Should
we
should
we
try
to
get
rid
of
the
the
full
mounting
behavior.
F
C
Can
it's
a
good
solution
to
fix
flaky
tests?
We've
set
this
time
at
once,
but
invariant.
It's
still
like
I,
said
at
hope
solution
and
we
should
try
to
unify
our
tests
and
I'm,
not
saying
we
should
be
great
to
shallow
mouths,
because
sometimes
you
really
need
to
mount
a
whole
component
of
a
whole
application.
There's
just
one
thing:
always
you
have
to
mock
all
related
stuff,
which
is
not
okay,
yep.
A
No,
that
makes
sense,
then,
let's,
let's,
let's
spend
a
little
bit
of
be
interesting.
I
think
like
what
is
what
is
taking
the
slowest
amount
of
time
here
so
I'm
gonna,
isolate
a
speck
and
we're
gonna
comment.
Things
out
just
see:
what's
taking
500
milliseconds
here
is
it?
Is
it
there's
full
mounts
or
is
it
maybe
some
of
the
processing
that
we
do
so
I'm
gonna
focus
on
this
one.
C
A
A
A
A
A
Let's,
let's
do
that
I
guess
what's
happening
is,
and
this
is
a
good
thing
to
keep
in
mind
of
for
the
speed
of
tests.
You
know
view
creates
listeners
for
everything
and
if
we
create
our
components,
we've
created
our
store
and
then
we
update
our
store.
It's
gonna
take
a
long
time
for
it
to
go
through
updating
all
the
listeners
as
opposed
to,
let's
just
create
everything
with
what
they
need
to
look
like
to
start
with,
so
we're
not
having
to
do
all
these
update
takes.
A
D
A
A
A
My
goal
is
to
rather
than
dispatching
this
action,
let's
see
what
happens
if
I
could
just
create
one
epic
of
what
we're
passing
into
here
and
replace
that
dispatch
receive
success
thing
with.
Maybe
these
calls
and
then,
if
that's
still
taken
a
long
time,
we
could
see.
Okay,
let's
see
what
is
art,
states
is
actually
changing
and
just
set
it
to
where
we
expect
it
to
be.
A
A
A
A
A
A
D
A
A
But
it
looks
like
it's
just
not
it's
not
that
action,
that's
taking
a
long
time
either
it's
that
action,
creates
lots
of
epics,
but
I
think
probably
what's
happening,
is
from
doing
a
full
mount
or
mounting
now
we're
probably
presenting
11
epics
and
doing
maybe
bunch
of
different
processing
from
there.
But
we
can
jump
into.
A
A
A
A
B
A
A
D
D
A
D
A
E
A
E
D
A
A
So
I
was
wanted
to
use
kind
of
like
profile.
It
was
gonna
comment
out
parts
of
the
parts
of
the
component
to
try
to
isolate.
What's
the
slow
part
of
doing
the
mount
here,
so
let's
say:
if
we
were
gonna
slice
it
and
do
you
know
as
much
as
we
we
had
before
if
I
go
to
my
still
focus
I'm,
not
focusing
why
let
me
go
and
focus
on.
D
A
A
I
don't
know
this
is
virtual
list
any
shoe
at
all.
Maybe
that's
a
feature
we
don't
even
have
the
feature
enabled
so
that
should
be
fine.
Maybe
it's
cuz
we're
generating
a
key
for
that.
Doesn't
sound
right.
Let's
go
to
epic
item
I,
see.
What's
the
dealio
here
updated,
maybe
that's
causing
some
problems.
A
A
A
But
I
doubt
we're
doing
anything
fancy
in
there.
So
I
wonder
if
it's,
because
my
well
I'm
really
curious
is
like
hey,
I
redoing,
some
like
something
like
created
events
on
some
some
element:
that's
gonna
get
rendered
a
whole
bunch
of
times
and
that's
gonna
cause
some
some
slowness
like
every
are
we
do
we
have
a
hook
on
an
element:
that's
not
like
a
top
level
on
it,
but
that's
you!
That's
rendered!
All
the
time
do
we
have
a
created
hook,
but
I'm
not
totally
seeing
something
like
that.
A
I
am
seeing,
though
we
just
create
a
whole
bunch
of
compute,
it's
like
and
that
that'll
that'll
slow
things
down
for
sure.
If,
at
my
store
level,
we
have
data,
but
then
I
have
to
all
of
my
components:
I
end
up
rendering
have
to
massage
that
data
and
create
Watchers
and
massage
it
and
create
Watchers,
and
just
that's
gonna
slow
things
down
for
sure.
So
I'm,
a
huge
fan
of
our
store
should
service
our
components
and
our
compiler
should
be
as
dumb
as
possible.
A
A
D
D
Singing
I'm
saying
that
if
we
go
and
optimize
this
component
to
render
faster
it's
going
to
help
us
in
the
app
yeah
I
think
maybe
we,
if
we
just
ignore
the
test
for
now
and
just
go
and
profile
it
in
the
actual,
app
and
see
what
is
taking
so
long
like
if
it's
shaking
like
a
few
hundred
milliseconds
for
just
just
a
few
epics
to
render
for
one
test
its
the
probably
in
the
browser.
Also,
it's
very
slow.
That.
A
Is
a
really
really
good
point
and
yeah
and
that's
that's
a
really
great
point
I
didn't
have
to.
We
don't
have
to
profile
this
in
this
test.
This
is
profiling
and
production
yeah.
That's
that's
a
great
point
and
I
think
it
emphasizes
why
having
these
timeouts
is
or
having
these
tests
fail,
when
their
slowest
is
huge,
because
then
I.
C
C
C
C
D
A
Bringing
it
back
yeah
these
kind
of
these
yeah,
these
look
look
the
same.
It
is
running
them
all
faster
now,
for
some
reason,
oh
because
of
me,
because
I'm
just
running
just
I
just
focus
on
these
I
wonder
if
maybe
this
isn't
even
getting
hit,
because
maybe
we're
never
actually
updating,
that's
a
good.
This
is
a
good
thing.
This.
C
A
This
is
a
good
find
I,
so
I
think
one
takeaway
and
I
really
like
what
you're
saying
is
we
can
profile
these
things
in
production
is
a
great
approach,
I've
seen
what's
slow
here
in
production
and
that
highlights
when
tests
fail,
because
things
are
slow.
That's
a
really
really
good
thing,
because
now
it's
highlighting
to
us
something
is
slow
in
production.
It's
not
like.
We
should
bend
over
backwards,
making
our
tests
fast.
Let's
see
we
can
make
our
production
code
fast.
A
That
would
be
ideal,
so
I'm
definitely
gonna
raise
an
issue
for
this.
We're
gonna
fix
this
flaky
spec.
With
this
approach,
we
should
raise
an
issue
saying
something
was
happening
when
I
ran
derd,
there's
a
huge
difference
between
rendering
one
epic
and
ten
epics
and
seeing
what's
what's
what's
the
cause
there,
and
could
we
make
this
better
awesome?