►
From YouTube: Magento MSI Open Demo. March 15, 2019
Description
Agenda:
- Async Operations in MSI and how to avoid Backward Incompatible Changes by @nuzil
- In-Store Pickup update by @Aleksandr
- In-store pickup infrastructure update by @ishakhsuvarov
- Fixed Travis builds (green tests are always a piece of great news to share) @ishakhsuvarov
- Integration tests for sophisticated scenarios of Qty Calculations by @joshcarter / @iminiailo
- Async Inventory sync up on product save. The final version by @TheRick
- Performance fixes on product save @ishakhsuvarov
- Product Grid. Fix performance degradation by @max
- Quality Report by @Tom Erskine
A
So
the
recording
has
started
so
we
can
proceed
with
the
medium
hi
everyone.
Today
we
have
today
we
have
the
MSI
weekly
meeting,
where
we
have
quite
a
lot
of
update
and
taking
into
account
that
some
of
the
guys
who
share
their
update
are
in
a
hurry
and
they
are
there.
They
won't
relieved
to
participate
on
the
magenta
meet
up
in
an
arc
here,
so
they
are
pretty
short
on
time.
So,
let's
not
let's
proceed
with
their
presentation.
B
C
B
Then
this
one,
this
code
is
executing
general
vector,
I'll,
run
a
synchronous
operations,
and
here
when
the
preceding
the
published
mess
method,
they
use
the
direct
topic
names.
So
that's
one
case:
it's
also
for
an
assign
and
also
for
transfer
pros
and
basically
those
names
they
provided
there
by
magenta
core
and
by
Magento
a
synchronous
operation
module
now
I
want
for
Magento
Weber,
PS,
sync
module
that
will
generate
those
names
based
on
a
web
api
XML
declaration.
B
So
it's
going
through
all
endpoints,
collect
the
data
and
then
create
those
topic
names
based
on
it
and
all
was
good.
Till
till
now,
I
would
say
person
to
three
one.
This
topic
name
were
changed
yeah
we
had
other
discussions.
Is
it
that
incompatible?
Yes
or
not,
but
you
follow
the
rule
or
like
the
dev
dogs,
which
are
rule
in
this
case
it's
baggage
incompatible
changes.
B
This
mean
we
have
currently
the
problem
that
for
those
topic
names,
this
operation
will
not
work
and
what
I
deliver
it
like
today,
I
made
a
small
changes.
So
basically,
my
idea
was
to
keep
the
two-30
competitive
compatibility
for
MSI.
So
because,
like
easiest
way
is
just
change
here,
the
topic
names
to
the
current
ones,
which
will
work
for
two
three
one
perfectly,
but
it
will
destroy
it
with
zero
compatibility,
because
in
two
three
zero
the
topics
are
still
has
an
old
Dame's.
B
So
what
I
did
I
created
two
files,
which
required
by
imagine
the
queuing
system?
It's
communication,
XML,
XML
and
key
publisher,
and
usually
those
two
files
as
they're
generated
by
whether
it
be
a
simple
on
a
fly
so
basically
like
inside
of
the
configuration
that
rated
based
on
of
API
XML
so
based
on
the
endpoints
and
well,
what
I
did
I
basically
create
here's
all
three
topics
which
MSI
is
still
using
with
an
old
format,
yeah
and
just
forward
them
again
to
to
the
bulks.
B
Also
then,
on
this
step,
all
implementation
dates
exactly
the
same
as
the
native
web.
Api
sync
is
using
and
yeah
so
I
created
those
three
topics
here,
which
for
all
two
would
forward
it
to
bulk
and
basically
then.
In
addition,
we
need
to
publish
her.
That
system
have
to
know
that
those
topic
names
are
going
to
the
human
system
systems
that
still
have
to
be
done
manually
in
this
case,
for
each
topic,
yep
and
basically,
with
these
changes
as
I
test
it.
B
Today
it
works
fine
and
it
will
keep
the
compatibility
with
two
three
zero
and
also
two
three
one.
Then
I
would
still
may
be
proposed
to
sing
this
solution,
because
I'm
still
not
too
convinced
that
we
use
in
here
the
hard-coded,
the
topic
names,
but
I
get
that
some
topic
for
future
discussions
in
I'm
done
eager.
If
anybody
have
any
questions.
A
Really
good
point
that
we
probably
it's
better
to
use
some
kind
of
abstraction,
probably
the
same
one
which
we
have
rolled
him,
because
we
don't
use
the
precise
protein.
We
have,
the
abstraction
which
could
be
configured
as
well
as
like
we
don't
use
like
with
the
even
handling
we
also
have.
Some
kind
of
abstraction
and
listeners
can
just
listen
that
that
event
beyond
being
fired
so
yeah.
A
This
is
a
good
point
to
introduce
abstraction
that
abstraction
supposed
to
be
an
API
for
the
for
the
cue
interrogation,
but
not
the
particular
topic
name
and
that
probably
will
mitigate
the
risk
of
the
backwards.
Incompatible
changes,
confusion,
yep,
but
in
any
case
here.
So
as
all
it
said,
we
have
a
pool
request
which
will
we're
supposed
to
fix
the
problem
both
for
to
the
street
at
all
and
to
the
street
at
one.
So
that
lets
you
just
hurry
up
a
squeeze
release
in
the
next
MSI
release
as
soon
as
possible.
You're.
A
So
the
next
one
gonna
be
colleagues
who
is
also
going
to
attend
the
kharkiv
magenta
Meetup
and
the
Alexander
will
Alex
Alex,
and
so
this
is
a
exactly
same
name
but
pronounced
on
Russian
style
and
the
cranium
style.
So
Alexander
will
tell
us
a
little
bit
more
about
the
in-store
pickup,
so
the
Alexander
represent
the
iesson
company
and
guys.
So
we
have
a
really
literally
saying
the
team
who's
dedicated
for
the
in-store
pickup
project
and
Alexandra
leads
this
team
and
he
will
he'll
tell
us
more
about
that
update
on
the
track
so
Alex.
D
Guys
eager
thank
you
for
introduction,
so
my
message
today
will
be
short.
We
just
put
first
brick
in
this
wall
of
in-store
pickup
functionality
from
a
SME
company
I.
This
few
days,
I
have
worked
for
the
small
issue.
The
idea
of
this
issue
is
to
create
some
mechanism,
how
we
can
mark
our
orders,
which
have
placed
with
installed
the
copper
shipping
method
and
align
them
with
source
which
well
they
will
be
delivered.
So
the
idea
of
this
functionality
I
will
share
my
screen.
Second,
oh.
D
Okay,
probably
not
today,
because
I'm
using
a
web
browser
version,
so
just
listen.
So
as
the
idea,
this
functionality
is
to
add
an
extension
attribute.
It
was
the
order
entity
which
will
keep
information
about
the
doors
which
the
order
will
be
deliberate
and
then
customer
can
gain
with
ship
it
and
take
it
and
grab
it.
Yes,
this
is
thank
you.
This
is
my
request
and
with
this
I
would
like
to
discuss
a
few
points.
D
First
point
is
related
about
alignment
with
the
domain
model,
as
we
previously
have.
A
discussion
is
that
in
in
talking
about
a
case
of
store
pickup,
so
for
now
we
have
inventory
source,
it's
like
a
place
where
goods
are
keeping
so
and
if
we
are
going
to
talk
about
a
place
where
customer
can
come
and
drop
his
order.
D
For
now
for
current
realization,
it
will
be
actually
the
same,
so
an
inventory
source
will
be
and
like
pickup
point,
but
as
we
have
discussion
about
possible
issues
with
translation,
the
localization,
like
naming
of
address
of
the
pickup
point
in
future,
probably
will
be
segregated
into
separate
identities.
And,
in
my
my
poor
request,
I
start
to
name
this
relation
between
order
and
source
like
pickup
point
and
use
a
column
named
pickup
point
ad
to
to
join
this
two
entities.
This.
E
D
C
E
D
D
So
for
now
we
decided
to
keep
it
the
same,
but
for
sir
party
developers
I
think
it
will
be
an
option,
so
they
can
use
the
Magento
MSI
inventory
sauce
entity
or
they
can
create
their
own
entity
like
pickup
point,
probably
if,
in
the
future,
in
scope
of
MSI
and
store
pickup,
we
also
will
use
the
other
entity
and
I.
My
idea
is
to
keep
this
this
dependency
as
soft
as
possible.
E
Right
from
a
merchant
perspective,
I
want
to
make
sure
that
they
have
the
same
experience
now
or
they
can
configure
a
source
decide
if
that
source
is
eligible
for
pickup
I
think
it
would
be
a
poor
experience
if
they,
if
we
were
to
introduce
in
the
future,
say
a
new
section
where
they
now
have
to
manage
sources,
stocks
and
pickup
points,
so
there's
three
different
things
that
they
have
to
manage.
That
is
probably
too
much
complexity
for
them,
given
that
they
could
manage
the.
What
we're
calling
pickup
points
here
within
the
sources
grid.
D
A
That
was
actually
the
idea
to
bring
the
current
meeting
and
discuss
your
opinion
mark
whether
we
need
to
introduce
this
additional
entity
right
now.
Maybe
maybe
we
should
not
make
too
many
complication
at
this
point
of
time
and
like
like
whether
we
introduced
such
an
entity
like
the
pickup
point
and
in
general
like
whether
that
pickup
point
even
naming,
is
correct
one
and
whether
it
makes
sense
just
to
stay
with
the
source
grid
and
some
kind
of
attribute.
Maybe
you
know,
attributes
for
the
sources
which
are
legible
for
the
store,
pickup.
E
D
D
Okay,
so
my
next
point
is
about
join
processor
for
the
extension
attributes,
so
I
found
that
and
the
order
entity
is
the
entity
which
don't
use
the
joint
processor
for
extension,
attributes
in
I
get
list
method
in
the
order.
Repository
so
probably
I
think
it
will
be
a
good
idea
to
give
opportunity
to
use
this
reckon
native
magenta
functionality,
not
only
for
not
only
for
customer
others
and
other
entities,
but
also
for
order,
because
for
now
we
can,
as
I
tried
as
I've
created
new
extension
attribute,
but
I
can
cannot
use
it
in
the
collection.
D
A
A
Actually,
the
Croatian
like
yeah,
because
I
believe
that
we
can
proceed
with
the
same
flexibility,
let's
say,
but
just
introducing
another
service
which
will
just
return
you
all.
The
sources
are
visible
for
the
in-store
pickup
and
that
that
would
be
just
dedicated
service,
but
I
wanted
that
we
would
not
be
introducing.
It
is
no
entity
so
because,
like
for
institutions,
a
new
entity,
we
have
really
supposed
to
have
quite
a
strong
reason
in.
A
Why,
like
what
the
business
cases
is
supposed
to
cover,
I,
really
like
the
level
of
abstraction
in
most
of
the
in
most
of
the
cases.
But
along,
is
that
I
believe
that
additional
abstractions
and
to
use
a
additional
level
of
complexity
both
for
this
case
both
for
merchants
and
the
for
developers,
because
merchants
also
have
to
some
somehow
differentiate
like
the
sources.
Turcica
points
and
the
way
how
the
store
pickup
went
can
be
much
too
sources.
D
Ok,
ok
and
the
last
my
point:
it's
about
in-store
pickup
shipping
method
and
it's
about
shopping
cart,
page.
So
in
on
the
shopping
cart
page,
we
have
like
estimated
shipping
and
tax
and
section
where
a
customer
can
enter
his
country,
state
and
zip
code
and
receive
the
estimation
of
shipping
costs
and
the
tax
also
customer
available
to
select
shipping
method
which
he
or
she
preferred
to
use
to
deliver
his
or
her
order.
D
So
question
is:
are
we
going
to
also
add
in-store
pickup
shipping
metal
method
to
this
section,
so
it
will
require
I,
didn't
like
drop
down
and
search
possibility
to
figure
out
which
source
will
be
used
not
only
on
the
checkouts,
but
also
on
the
chicken
cart
step
and
as
a
question.
We
can
just
hide
the
shipping
method
from
the
cart
step
and
shipping
method
will
be
only
available
on
the
checkout
page.
E
This
is
the
part
we
actually
we
have
not
groomed
yet
so
the
the
mock
up
designs
we
did
with
our
UX
team,
are
more
past
this
page.
So
after
you've
already
clicked
proceed
to
checkout,
we've
done
some
designs
of
how
the
customer
would
select
a
regular
shipping
method
or
in-store
pickup,
and
if
they
pick
in-store
pickup,
how
did
they
select
the
correct
store?
We
haven't
groomed
what
we
do
with
this
estimator.
A
A
Thank
you.
Thank
you,
Tasha
for
your
your
update.
It's
really
matters
and
like
the
next
week
I
will
I
will
I
will
schedule
the
meeting
and
where
we
can
discuss
the
topics
you
brought
up
for
today,
so
yeah.
So
now,
let's
proceed
to
further
updates
and
you
again
will
will
tell
a
little
bit
more
about
the
in-store
pickup,
also
to
Virginia
feel
free
to
share
your.
F
Screen
share
so
there
are
not
too
much
updates
at
this
point
most
as
most
of
them
are
really
short
and
quick.
So
we
decided
to
separate
so
pickup
into
a
separate
branch
on
the
repository
which
is
based
on
two
point.
Three
develop
two,
basically
all
store
pickup
related
TRS
are
supposed
to
go
to
the
store,
pick
a
branch.
Actually,
we
have
already
merged
some
of
the
pull.
F
This
point
we
already
have
three
modules,
which
are
the
basic
module
structure.
I
think
I
think
one
of
these
Qwest
yeah,
this
one
I
suppose,
has
implemented
that.
So
these
files
are,
it's
mostly
just
empty
modules,
but
served
it
as
a
base
for
the
future
development.
We
have
also
accepted
a
few
pool
requests
on
top
of
that.
One
of
them
is
a
really
good
one.
F
It
provides
an
API
to
select
the
store,
pickup
points
based
on
the
customers,
preference
of
distance
from
these
Pacific
postcode,
though
this
current
implementation
utilizes
something
called
Great,
Circle
distance
algorithm
and
it's
calculated
using
the
sophisticated
database
query,
but
other
implementations
may
also
be
supplied
by
developers
to
implement
it
in
a
different
way.
This
is
pretty
much
the
first
API
for
the
sort
of
atop
modules.
F
F
F
A
F
What
is
which
module
we
we
have?
Currently,
we
have
three
modules
in
store:
pickup
store,
pickup
admin,
UI
and
API.
All
of
them
are
dedicated
to
separate
purposes
or
pickup.
Api
only
provides
api's
which
may
be
used
or
from
like
applied.
The
different
implementation
insert
pickup
module
contains
all
the
stock
business
logic
which
we
provide
with
the
like
MSI
installation,
and
that
means
UI
speaks
for
itself,
just
module
related
for
admin
UI
again
it's
something
what
you
can
swap
out
or
disable
completely.
A
Okay,
like
just
to
prevent
the
discussion
like
but
I,
propose
to
keep
the
discussion
in
chat
and
based
on
what
you've
just
told.
We
have
another
question
to
mark,
because
we
were
already
stuck
with
that
during
the
implementation
of
the
distance
based
algorithm,
and
should
we,
what
do
you
think
should
be
introduced
any
layer
of
abstraction
on
the
on
the
distances
we
use,
because
currently
we
can
like
draw
to
system
metric
system
and
imperial
system
and
currently
most
of
the
like.
A
Most
of
the
values
we
use
like
belongs
to
the
metric
system
and
like
Google,
Google
Maps
API.
Consider
the
metric
system
as
a
default
option,
but
currently
for
us,
like
it's
not
possible
to
specify.
So
we
don't
have
kind
of
distance
object
where
you
can
specify
that
this
object
should
have
the
Imperial
presentation
or
metric
one.
So
if,
for
example,
somebody
will
decide
to
make
the
customization
for
United
States
and
use
miles
instead
of
kilometers,
it
would
be
little
bit
more
problematic
than
having
a
dedicated
dedicated
like
object
and
API
to
to
customize.
A
E
Yeah,
we
should
probably
add
that
to
this
upcoming
grooming
meeting,
I
mean
my
first
thought
would
be
it
doesn't
matter
if
we
don't
display
anything
to
the
customer.
So
then
it's
just
you
know
which
number
is
smaller
than
another,
but
if
we
intend
on
the
UX
and
the
front-end
to
show
the
list
of
stores
based
on
the
address
they've
entered
at
the
point,
they've
entered,
it
will
sort
them
by
distance
and
list.
You
know
this
is
ten
kilometers
away.
This
is
40
kilometers
away.
E
A
What
they
actually
have,
they
have
the
dedicated
parameter
units
which
is
supposed
to
be
configure
it.
Whether
either
in
metric
or
imperial.
The
metric
is
the
default
value.
But
for
all
the
API
requests
it's
possible
to
specify
the
metric
parameter
units
parameter
so
that
you
will
get
the
result,
whether
in
meters
and
kilometers
or
in
miles
and
feeds.
A
E
We
probably
do
only
the
reason.
I
say
that
is
because,
if
we
are,
if
we're
going
to
prompt
the
customer
on
the
front
end
to
have,
that
is
something
they
can
pick
like.
If
they
are
able
to
pick,
you
know
10
25,
50
100
miles,
then
we
needed
to
calculate
it
in
the
same
way.
I
would
much
rather
send
this
parameter
and
accept
Google's
results
than
trying
to
do
calculations
on
her
own.
A
Mm-Hmm-Hmm
yeah,
so
we
wouldn't
be
making
the
calculation
in
our
or
we'll
just
be.
We
will
just
keep
that
like
tips
and
extending
that
current
value
is
in
represent
the
distance
and
miles
and
current
value
represent
distance
in
kilometers.
But
all
the
calculation
would
be
done
by
let's
say
third
party
service
like
Google
or
so.
We
would
not
be
like
making
the
conversion
correct.
E
Then,
ideally,
we'll
have
to
have
a
setting
for
this,
and
the
best
way
to
do
that
would
be.
If
that
can
just
pull
off
one
of
the
other
regional
settings.
We
already
have
in
store
configuration
by
default,
so
the
the
merchant
could
override
it,
but
it
would.
It
would
pick
up
what
they
already
had
set
for
other
elements
of
Magento.
A
Okay
looks
like
we're
clear
on
that
point
in
it
like,
in
any
case,
I
believe
on
the
upcoming
MSI
grooming
meeting
devoted
to
the
store
pick
up
will
bring
more
like
ideas
and
maybe
proposals
Agana,
how
that
could
be
how
that
could
be
done
and
how
that
could
be
represented
on
the
UI
but
yeah.
This
is
the
issue
we
started
to
think
about
during
this
week.
A
A
Mean
quantity
threshold
you
know,
okay,
that
gonna
be
plus,
because
minus
minus
3
gives
us
plus
3,
and
he
couldn't.
He
couldn't
replicate
that
issue.
If
the
quantity
was
just
was
just
a
fraction
of
off
like
1,
so
that
the
calculation
was
precise.
So
my
first
thought
that
we
somehow
somewhere
have
that
incorrect
calculation
for
the
decimal
quantity,
but
taking
into
account
that
I
couldn't
reproduce.
This
issue
manually
like
here,
for
example,
what
I
proposed
I
proposed
to
George
tartar
to
write
an
integration
test
and
cover
that
functionality?
A
F
Cache
cleans
always
relies
upon
the
dirty
object,
State
and
implemented
like
some
redundant
work.
Each
time
the
product
was
save
and
the
execution
time
was
the
increasing
linearly.
So
this
simple
fix
improved
performance
by
I
think
around
80%
we
had
some
some
rough
numbers,
and
here
it's
yeah
for
2,250
products.
The
improvement
is
really
significant,
really
great
pool
request
and
it
was
was
pleasant.
Merchants
yeah.
We
have
too
much
to
say
yeah.
A
But-
and
we
can
see
there
that
this
is
the
main
root
cause,
because
we
have
to
synchronize
inventory
the
data
both
for
legacy
legacy
inventory
into
the
new
inventory
databases,
but
looks
like
we.
We
did
not
notice
that
we
have
a
gap
with
the
cash
cleaning
and
this
cash
gap
and
actually
fixing
that
gap
introduced
pretty
pretty
good
performance
boost
for
the
product.
Save
operation.
A
So,
yeah
that
this
is
really
great
pool
request
and
it's
really
nice
to
see
that
guys
from
community
like
fill
the
gaps
which
we
don't,
which
we
don't
notice
for
some
some
reasons
and
yeah,
and
that
was
all
the
preface
for
the
for
the
presentation
which
which
will
require
they're
gonna
gonna,
do
right
now
regarding
the
finalizing
of
his
pool
request
on
the
on
the
inventory,
save
operation
and
making
all
that
sink
part
to
work.
Asynchronously.
G
I
was
just
trying
to
share
my
screen.
Okay,
can
you
see
my
screen?
Yep?
Okay,
cool?
So
basically
this
is
I
finalized.
The
the
work
I
started
last
week,
though,
basically
is,
as
you
told
before,
one
of
the
most
important
water
neck,
while
saving
the
cementery
was
the
legacy
metric
synchronization,
and
so
this
pull
request
basically
is
running
the
synchronization
in
a
synchronous
way.
G
A
Cool
Thank,
You,
Ricardo
and
especially
based
on
the
base
and
the
update
of
Alex.
Listen
even
if
Ricardo
is
using
the
old
topic
names,
his
pool
request
wouldn't
be
affected
because
in
the
poet
was
created
by
Alex,
introduce
the
configuration
and
Martin
of
the
old
topic
names
to
the
new
handlers.
So
now
we
can
use
like
boss,
like
all
the
new
topic
names
and
that's
supposed
to
work
well,.
A
Today,
today,
I
will
try
to
nourish
both
of
your
pull
request
altogether
and
also
add
the
pull
request
with
this
cache
invalidation
and
to
run
all
our
performance
exceptions
test
to
see
the
difference.
Comparing
is
what
we
had
on
a
on
a
previous
MSI
branch
and
the
especially
way
interested
in
the
product
save
operation.
A
It's
evidently
that
we
have
some
memory
leakage
there
and
we
started
to
investigate
that
issue,
because
initially
we
thought
that
the
problem
could
be
in
like
maybe
in
handling
like
bundle
products
or
which,
which
is
currently
not
supported
on
a
default
source,
but
looks
like
this
is
not
the
case
and
the
bundled
product
would
be
handled
correctly,
even
for
default
source.
So
we
like
this,
probably
update
for
Laurie.
So
we
no
need
to
add
any
any
additional
stuff
to
our
documentation.
A
No
need
to
add
additional
labels
on
the
U
on
the
admin
UI,
so
that
we
are
pretty
good
from
that
point
of
view.
But,
along
with
that,
we
like
drawer,
still
investigated
the
issue
with
importing
big
profile
and
while
why
actually
the
source
import
going
pretty
slow.
So
we
tested
that
on
100,000
source
items
to
be
imported
and
that
took
more
than
one
hour
so
like
because
taking
into
account
that
we
using
the
bulk
inserts
it
should
be,
it
should
be
weaker.
A
So
we
expect
that
some
like
update
index
on
save
operation,
probably
reason
or
of
this
performance
degradation
currently
have
on
the
source,
import,
I
I,
hope
that
we
will
have
this
issue
fixed
and
demonstrated
on
the
next
on
the
next
meeting.
Also
a
small
update
to
Priya.
So
we
have
a
contributor
who
just
left
because
he
was,
he
was
hurry
up
to
the
to
the
magenta
meetup.
So
Stefan
Stefan
already
created
the
first
full
request
regarding
the
stock
export.
A
He
introduced
there
the
set
of
interfaces
and
he
is
going
to
continue
that
work
during
tomorrow's
contribution
day.
That
I
really
will
have
the
implementation
of
the
stock
export,
including
the
including
the
reservation.
So
they
taken
reservation
into
account
so
that
you
can.
You
can
rely
on
that
pull
request
further
and
you
can
relied
on
that
piece
of
functionality
in
the
scope
of
the
integration,
with
the
sales
channel,
where
magenta
integrated
and
expert
the
inventory
data
to
do
to
Amazon
and
a.
A
Welcome
I
believe
that
we
will
have
more
updates
during
this
during
next
week,
when
Stefan
will
manage
to
finalize
this
request.
I
don't
see
yeah
I
see.
Oh
my
gosh
Lucas
on
the
meeting,
so
Lucas
created
a
fully
request,
literally
like
one
hour
before
the
demo.
So
Lucas.
Would
you
like
to
share
your
update
on
what
you
did
for
Emma
side.
C
Ok,
it's
not
much,
however,
when
doing
my
usual
job
I
found
out
that
there
is
one
method
I
want
to
extend
and
then
I
try
to
discuss
about
it
and
eager
notice
that
it's
incorrectly
it's
incorrect.
Seeing
shows
that's
that
it's
available
to
to
modification,
because
there
was
there
was
lack
of
replication
information
in
those
interfaces.
So
I
modified
this
to
SBI
to
me
from
programmers
that
it's
no
longer
supported
that
if
it's
deprecated
we
can
see
in
my
screen,
probably
with
this
information
to
SBI's
in
couple
of
inventory.
A
A
A
A
This
degradation
is
not
related
with
configurable
products,
as
many
people
kinds
of
joke
in
the
Messiah
Channel.
So
this
is
the
main
root
cause
of
the
degradation
is
a
saleable
quantity
column,
because
from
the
msi
standpoint,
we
never
considered
that
we
supposed
to
work
and
supposed
to
get
quantities
from
different
different
stocks
in
one
business
scenario,
because
on
front-end
we
always
work
in
the
scope
of
one
stock.
Only,
but
just
for
this
scenario
to
show
the
different
quantities
or
admin
on
different
stocks.
A
A
This
the
same
number
of
service
requests
here
and
each
of
the
service
requests
will
end
up
having
the
SQL
query
to
particular
stock
table,
so
that
agent,
this
table
introduced
quite
weighted
like
quite
a
drastic
performance
degradation,
especially
for
those
merchants
who
have
quite
a
lot
of
stocks
and
from
like.
There
is
no
like
an
easy
way
to
mitigate
this
performance
degradation
because
in
any
case
we
have
the
independent
API
is
in
any
case,
we
have
independent
tables
in
our
database
and
all
the
tables
supposed
to
be
queried
to
retrieve
the
data.
A
A
Discover
this
pull
request,
so
we
try
to
build.
You
can
see
it
here,
so
we
tried.
We
decided
to
consider
that
this
data
is
kind
of
important
data,
and
it's
a
key
for
like
to
build
this
to
build
this
product
grid.
It's
a
key
to
retrieve
the
data.
Not
we
imply
interface
but
like
with
the
direct
SQL
queries
so
that
we
are
trying
to
mitigate
the
performance
degradation.
H
Yes,
we
do
ok,
thank
you,
so
quality
status
for
the
previous
week.
So
what
we'll
see
here
is
that
we're
currently
in
the
middle
of
a
regression
run
for
one
one,
Oh
full
manual
and
automated
run.
So
in
terms
of
our
manual
testing,
we'll
see
these
numbers
haven't
changed
as
we
see
six
or
two
six
or
two
previous
week
and
current
week
of
total
manual,
an
automated
of
stayed
the
same
because
we're
in
the
middle
of
that
manual
test
run
and
that's
where
the
focus
is.
The
change
in
numbers
is
here.
H
H
That's
the
main
bulk
of
where
we've
been
working
in
in
terms
of
automation,
execution,
statuses
are
the
same
again
we're
still
running
with
those
twelve
skips.
That's
a
backlog.
That's
due
to
be
dealt
with
and
we
have
some
community
contributors
from
each
test
vast
contribution
day.
Last
Friday
working
on
some
tasks
to
contribute
and
those
are
not
finished.
H
Yet
that's
a
bit
of
a
learning
exercise
for
FTF
contributors,
so
those
are
a
little
slow,
but
we
hope
to
get
them
in
soon
very
clean
best
practices
with
merges
and
extends,
so
we'll,
hopefully
see
those
by
next
week.
Our
test
creation
trend,
as
I've
said,
is
flat.
That's
because
we're
right
in
the
middle
of
an
execution
run.
H
We
expect
once
we
finish
that
up
to
then
bring
these
numbers
up
again
and
we
hope
I
think
to
be
finished
by
our
manual
execution
by
next
week,
but
we'll
update
on
that
in
our
next
call
and
what
we're
adding
to
your
quality
reports
for
these
weeks
is
that's
coverage
and
execution
we've
been
looking
at,
but
we
also
want
to
look
at
our
defects,
our
rid
of
creation
and
closure.
The
moment
we're
just
gonna
highlight
the
last
week
we'll
make
this
a
little
more
sophisticated
as
we
go
and
do
tracking
trending
as
well.
H
Both
in
the
last
week,
we've
had
six
issues
created,
of
which
two
were
highlighted
as
bugs
and
the
me
invoke
there
being
twenty.
Seventy
nine
sources
with
a
purely
numerical
source
code,
couldn't
be
used
in
shipment
at
all
that
was
opened
and
then
subsequent
the
same
person.
Who
is
it?
That's
I'm
an
Arabic.
H
So
we
got
that
closed.
In
the
same
week,
there
was
another
bug
raised
pilot
here
at
the
bottom
20
73,
and
this
is
still
open
it
in
MSI
bug
tracking
but
has
been
moved
to
a
core
issue.
It's
not
a
MSI
issue,
Kureshi
around
two
to
two
to
three
upgrades,
but
it's
still
open
an
hour.
So
it's
tracked
here
until
that
whole
process
is
closed
right,
but
yet
we
find
one
bug
we
closed
it.
H
A
A
Message
queue
topic
renaming
and
that
we
do
not
have
precise
test
case
covering
that,
because
our
existing
integration
did
not
cover
that
that
we
had
a
bug
on
the
asynchronous
inventory
transfer
I
asked
Slava
to
in
to
cover
this
particular
case
with
additional
test
case
in
our
hip
test,
so
I
believe.
If
the
next
time
the
topic
name
would
be
changed
and
that
will
screw
up
the
MSI.
So
we
can
find
that
that
issue
much
earlier
on
the
at
the
time
of
the
regression
fantastic.
A
If
no
probably
we
can
wrap
up
for
today
and
think
you
guys
for
a
time
think
guys
were
presentation.
Most
of
people
are
already
departed
to
the
contribution
days
and
the
meetups.
We
have
two
of
them
right
now,
starting
in
Ukraine
and
yeah.
Thank
you
guys
for
your
time,
appreciate
your
help
and
see
you
in
a
week.
Thank
you.