►
From YouTube: Node Operator Roundtable - July 5th, 2023
Description
The Node Operator Roundtable discusses Leap 4.0 patch releases, increasing block sizes, block relay nodes, ship issues, and more!
00:00:00 Welcome
00:00:11 This Weeks Agenda and Topics
00:03:39 Leap 4.0.4 Patch Release
00:13:03 Increasing Block Size
00:34:21 Block Relay Nodes
00:39:53 Ship Issues
The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.
// EOS Network Foundation //
https://www.eosnetwork.com
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosnetwork.com
#EOS #Web3
B
Excellent
good
morning,
good
afternoon,
good
night,
everyone
thanks
for
joining
the
call,
we're
gonna,
kick
it
off
with
some
quick
agenda
building
to
get
to
get.
You
know,
what's
on
everybody's
Minds,
we'll
try
to
keep
these
high
level
at
first
and
not
go
into
details
so
that
we
can
capture
the
list
and
then
prioritize
that
list
as
a
group.
B
C
We
want
to
test
vision,
four
or
dot
whatever,
and
we
want
to
test
it
on
wax,
which
is
the
the
busiest
network
of
them
all.
It's
the
one
that
we
can
really
it's
all
great
to
do
on
test,
Nets
and
everywhere
else,
but
if
you
really
want
to
get
a
litmus
test
or
how
good
the
software
is
rolling,
we
either
put
it
out
at
the
on
the
battlefield,
which
is
wax,
which
is
very,
very
busy
at
the
moment.
C
He's
like
yes,
but
I
believe
there
are
some
other
issues
and
Matthew
and
Michael
that
both
had
some
challenges
so
we're
we're
kind
of
at
now
is
we
we
want
to.
We
want
to
be
testing
providing
some
feedback,
but
we've
already
found
some
bags
and
that
make
it
rock
production
really
for
us,
and
you
know
we
just
want
to
get
some
feedback
that
you
know
we
all
everybody
wants
to
run
it
version.
Four
most
of
us
are
still
stuckman
version
is
three
on
wax.
Okay,.
B
D
Well,
it
sounds
like
there
was
some
request
to
change
the
configuration
in
Jungle
to
change
the
parameters
of
how
big
the
blocks
could
be,
and
apparently,
there's
been
some
testing.
That
shows
that
that
is,
might
be
reasonable
to
run
bigger
block
sizes,
more
transactions,
so
I'm
just
wondering
if
someone
could
share
what
the
process
was
to
come
up
with
those
test
results.
A
B
All
right
so,
let's
start
at
the
top
the
or
dot
X
stuff.
So
we
do.
We
do
have
a
another
sort
of
patch
release
play
End.
Details
on
that
are
coming
I
I'm,
not
sure
whether
the
specific
issues
that
are
blocking
doing
builds
for
wax
are
resolved
in
that
release.
So
that's
something
I'm
gonna
have
to
dig
into
I,
see
Kevin
kind
of
doing
a
tiny
little
head
shake
so
I'm
guessing
not
yes,
so
but
I'll
look
into
that
and
we'll
we'll.
B
E
A
C
Where,
when
we
we've
still
got
version,
four
that
we
actually
want
to
run-
and
you
know,
share
some
results
and
the
experiences
on
like
I
said
you
can
you
can
run
it
on
any
test
that
you
want,
but
no
test
net,
it's
the
same
kind
of
playing
field
as
something
that's
in
production,
so
you
know
we
can.
We
can
cover
our
base.
C
B
So
you
know
5.0
is
intended
to
be
sort
of
a
a
protocol,
upgrade
consensus,
release
thing
right,
so
there's
more
kind
of
coordination
and
and
lead
time
involved
with
actually
getting
it
deployed
on
a
network,
and
so,
as
a
result,
slippage
on
that
is,
is
challenging
and
like
can
cause
more
sort
of
Downstream
issues
of
like
causing
other.
You
know
the
next
release
to
be
delayed
and
and
so
on
and
so
forth.
B
So
you
know
if
if
there
are
folks
who
are
willing
to
participate
in
in
a
retrospective
sort
of
a
separate
meeting
that
wouldn't
be
recorded,
because
it
would
be
very
sort
of
what's
the
word
I'm
looking
for
ended
right
feedback
in
both
directions
and
that
sort
of
thing
you
know,
please
shoot
me
a
telegram
message,
because
that's
that's
something
I
think
I'd
like
to
get
scheduled
after
we've
resolved
some
of
these
issues
right.
The
focus
is
first
on
resolving
and
then
and
then
reflecting
right.
F
C
C
A
B
So
we've
got
there's
a
if
you're
sort
of
what's
the
word
behind
the
curtain.
Sort
of
thing
here,
like
we've,
got
kind
of
a
few
different
sort
of
statuses
right
like
so
one
is
triage
when
it
when
an
item
is
first
created
is
triage
and
usually
when
it
has
the
triage
label.
It
means
that
it
hasn't
been
sort
of
explicitly
prioritized
at
this
stage,
but
it
doesn't
mean
that
nobody's
looked
at
it.
B
B
You
know
the
the
typical
to
do
doing
done
type
stuff
right
in
progress
and
and
in
review,
like
those
sorts
of
statuses,
there's
also
a
status
called
icebox,
which
is
usually
things
things
will
drop
to
the
ice
box.
If
it's
it's,
not
necessarily
that
it's
not
important,
but
it's
sort
of
become
obvious
that
we're
not
going
to
be
addressing
it
in
the
near
term.
It's
just
sort
of
clean
up
so
that
the
signal
to
noise
ratio
can
be
kept
more
reasonable.
B
So
it's
not
deleted,
but
it's
hidden
from
view
for
us
for
a
while
right
and
we
periodically
review
the
ice
box
to
decide
if
something
should
be
Resurrected.
Anyway.
That's
maybe
details
that
you
didn't
ask
for,
but
you
know,
oh
there's
also
a
Sprint
I.
Just
guess:
I
didn't
talk
about
Sprints.
We
we,
when
we
add
things
to
a
milestone.
B
It
means
that
we
have
a
Target
release
in
mind
for
it
and
there's
some
technical
elements
to
that
too,
of
like
what
what
branch
we
want
to,
you
know
actually
make
changes
to
and
that
sort
of
thing
and
then
the
Sprint
when
it
when
it
gets
a
Sprint.
That
typically
means
that
we're
intending
to
work
on
it
over
the
next
week
or
two
so
yeah.
Those
are
some
signals
that,
if
you're
curious
and
on
spying
on
us,
you
could
you
could
sort
of
follow
that.
G
Which
can
be
a
bottleneck
floral?
You
know
when
we're
doing
performance
testing
technically,
if
we're
doing
like
transfer
performance
testing.
Well,
it
actually
net
bottom
back
before
we
get
any
sort
of
CPU,
probably
but
anyway
for
for
mainnet,
that's
typically
not
a
probability
cards.
Your
your
transactions,
you're
executing
typically
are
as
as
fast
as
just
as
some
token
trans
shorter,
typically
more
CPU
intents
than
that,
so
you
will
eventually
hit
a
CPU
Max
for
a
block.
G
So
there's
lots
of
changes
that
have
happened
since
we
kind
of
landed
on
to
200
milliseconds
it'll
live
with
200
milliseconds
for
a
long
time,
and
our
performance
runs
that
we
do
for
like
standing
up
big
chain
and
doing
other
performance
testing.
We
we
see
stability
at
much
higher
settings
than
that.
Now
now
granted
we're
not
doing
round
the
world
sort
of
performance
testing
there
in
charge
of
like
Network,
latencies
and
mass
sort
of
thing,
but
they're
you
know
there.
G
There
have
been
huge
amounts
in
the
treatments
in
the
way
that,
like
blocks,
are
consumed,
processed
and
the
way
transactions
are
also
processed,
and
so
we
feel,
but
we
that
it's
it's
time
or
it's
it's.
It's
appropriate
at
this
point
that
that
limit
can
be
increased.
You
have
500
milliseconds,
basically
a
block
time,
if
you
will
of
us
between
blocks.
G
At
would
be
accurate,
which
would
be
you
know.
One
reason
obviously
we'd
want
to
do
this
on.
You
know
jungle
test
act,
you
know,
granted
we
enjoy
the
test
status,
it
doesn't
have
below
the
US
main
ad,
but
and
then,
of
course
you
do
all
these
may
not
be
gonna
have
a
load
of
wax.
So,
like
you
know,
all
these
sorts
of
things
are
certainly
considerations
as
it
gets
rolled
out
to
various
chains.
B
G
We
certainly
could
they
don't
really
even
need
our
help.
They've
done
that
many
times
fast.
You
know
if
they're
willing
to
do
that,
they
they've
got
their
own
scripts.
That
they've
used
in
the
past
to
do
that
which
are
probably
more
than
than
capable.
They
certainly
could
use
the
performance
as
well.
I
mean
it's
you.
Could
it
could
do
that,
but
they've
got
they've
already
got
stuff
set
up
where
well,
they
can
it'd
be
easier
for
them
to
see
that
way,
as
opposed
to
using
our
scope.
D
G
I
mean
I
mean
it's
hard
to
answer.
No
to
a
question
like
that.
Right
I
mean.
Obviously
you
know
the
war
testing,
you
do
the
better
Ops
you
are
and
something
like
this
it.
It
works
doing
that
ultimately,
I
can't
I
think
it
kind
of
rules.
Well,
let's
just
laying
behind
here
in
Edwards
alternative.
You
know
stuff
like
this
has
to
go
on
Main
Nets,
to
really
see
what's
going
to
happen,
I
mean
yeah.
We
can
do
you
know,
load
testing,
all
we
want,
but
eventually
you
have
to
turn
it
on
well.
G
G
G
You
know
to
make
that
happen
where
you
know
you're,
just
such
a
slightly
larger
contract,
then
you
know
we'd
be
good
to
go
there.
So
there's
that
certainly
the
the
EDM
support
that
we
have
now.
A
lot
of
those
contracts
are
larger
than
what
we
might
typically
see
with
a
native
EOS
transaction
and
so
allowing
larger
types
of
medium
types
of
transactions
are
attractive
for
the
network
right,
so
whether
it's
a
larger
or
more
involved
types
of
slots
or
whatever
it
might
be,
or
even
just
setting
EDM
contracts.
G
You
know
that
that
allows
those
larger
crime
contracts
to
be
able
to
be
executed.
So
this
is
somewhat
in
tandem
with
the
other
thing
that
we've
been
talking
about,
which
is
increasing
the
the
node
classified
Mac
transaction
limit
from
30
to
the
on-chain
limit
of
150,
and
then
you
know,
I
think
we
would
then
talk
about
increasing
that
150,
potentially
up
to
maybe
249
or
something
like
that,
or
right
now
block
limits
200
to
199.
G
Let's
say
they
set
it
to
150.,
and
yes
that
does
get
you
in
a
situation
where,
if
somebody
submits
a
transaction,
the
runs
for
say,
149,
milliseconds
or
150
milliseconds
and
then
fails
then
yeah.
You
don't
have
a
lot
of
time
left
in
your
block.
We're
actually
doing
anything
else,
because
it'll
spend
your
entire
time
evaluating
the
transaction
that
ended
up
failing,
and
so
yes
there,
whereas
the
the
opportunity
for
that
to
happen
just
like
there
is
that
opportunity
today.
G
D
D
Yeah,
maybe
there
needs
to
be
a
way
of
like
we're
talking
about
Auto
OC
enable
for
certain
things.
Maybe
there
needs
to
be
a
way
to
well.
We
approve
these
people
to
have
higher
limits
for
CPU,
but
otherwise
the
Regular
Joe,
you
know,
uses
the
smaller
one
and
then
that
prevents
the
abuse.
I,
don't
know
like
okay,
the
ebm
contract.
We
trust
that
more
so
we'll
let
it
have
slightly
higher
transaction
time.
D
G
And
it's
already
in
5-0
is
yeah.
It
is
to
do
that
so
yeah
we
do
have
that
and-
and
we
have
talked
about
and
something
that
you
know
would
certainly
be
looking
for
feedback,
particularly
up
to
you
guys
by
around
the
5-0
is
whether
you
know
a
white
list
for
the
The
ROC
is
something
that
would
be
useful.
You
know
right
now
in
5.0.
G
What
the
autoc
will
do
is
provide
OC,
tear
up
for
eosio.star
accounts,
which
includes
you
know
token
and
include
EDM,
but
you
know,
but
but
anything
else,
ibc's
marchig,
all
those
benefit
from
that.
Whether
there
is
appetite
or
enabling
that
or
BPS
being
able
to
enable
that
for
a
given
whitelisted
set
of
accounts
that
aren't
just
esio.
E
G
Right,
whether
there's
like
a
different
Max
transaction
time
for
a
white
listed
said,
yeah
of
accounts
as
well,
yeah
I
mean
that's.
That's
interesting,
I'm,
not
sure
that
we'll
actually
considered
consider
that.
But
that's
that's
interesting.
One
thing
that
you
have
talked
about
recently,
which
I
think
is
a
great
idea
as
well,
is
to
have
a
a
different
limit
for
Max
transaction
time
for
a
PDP
transaction
versus
an
API
transaction.
D
G
They
are
identical
matter
of
fact,
the
way
it
works
and
detention,
the
most
conservative
yeah.
It
takes
the
most
conservative
of
the
two.
So
if
you
think
you're
setting
something
different
when
you
set
one
than
the
other,
no,
they
actually
both
manipulate
the
exact
same
variable
in
the
code.
That
was
just
done
as
a
backwards
compatibility
thing
back
when,
when
we
did
it
yeah
and
I,
think
we're
probably
long
past
like
getting.
G
G
C
E
C
G
Larry
Jack
is
saying
the
CPU.
The
percentage
is
just
it
just.
Does
the
calculation
and
calculates
the
offset
and
then
uses
the
offset?
So
that's
that's
all
enjoy
going
on
there.
You
can
do
it
you're
as
a
as
a
literal
value,
or
you
can
do
it
as
a
percentage
and
again
like
it
it
whether
you
said
it
or
not,
like
their
default
comes
in
place.
Well,
it
it
always
chooses.
The
less.
Are
the
more
conservative
of
the
two
values,
more
conservative
here,
meaning
smaller
smaller
block
time?
That's
allowed.
A
D
Yeah,
so
let
me
clean
that
up.
I
think
that
would
be
a
good
thing.
The
other
assets
you're
talking,
if
you
since
we're
talking
about
this.
So
if
we
have
one
of
those
failed
transactions
that
takes
the
entire
block
time,
but
our
block
is
actually
early
now
because
we
already
shuffled
them
all
up,
will
the
block?
Can
we
extend
the
block
time
so
it
keeps
going
until
it
reaches
its
limit
on
the
schedule
time
yeah.
G
Okay,
that's
good
yep,
that's
the
way
to
work
yep,
that's
actually
the
way
it
works
now,
except
the
difference
between
what
we
have
in
50
now
is
now
we
always
start
a
block
at
this
at
the
second
or
half.
Second
interval,
no
matter
what
that's
the
part
that
we're
changing,
that
we
won't
necessarily
always
start
and
block
exactly
at
a
second
or
a
half
second
yearbook,
a
block
can
start
early
if,
if
we've
exhausted
the
previous
one,
but
only
if
we
put
that
comes
off.
D
G
Yes,
yeah,
and
so,
if
you
have
those
still
transactions,
you're
talking
about
yeah
and
win
5-0,
it's
gonna
be
better
because
you
don't
have
more
time
to
like
realize
those
still
transaction
because
you're
going
to
be
doing
it
early
because
what
happens
now
and
4L
and
everything
prior
to
it.
You
start
always
at
second
and
half
second
clock
time,
always
right
right
on
right
on
the
dot
and
so,
but
you
only
have
until
the
end
of
that
of
that
time,.
D
D
D
So
I'm
trying
to
figure
out
that
say
more
yeah:
it
causes
a
lot
of
extra
infrastructure
right
just
to
re,
run
a
node
to
relay
blocks
match
it.
So
we
had
previously
had
a
discussion
about
well,
maybe
we
can
come
up
with
like
a
light
node
that
doesn't
keep
any
state
or
whatever
and
knowledge
its
job
was
to
relay
blocks.
D
But
then,
since
we
had
that
conversation,
we
actually
well,
we
I
didn't
do
anything
about
it,
but
you
know:
Kevin
and
the
rest
of
the
dev
team
did
a
lot
of
work
to
make
sure
that
the
blocks
are
pushed
out
first
rather
than
dealing
with
the
transactions.
So
maybe
that
mitigates
the
whole
problem
and
then
we
can,
just
you
know,
save
a
whole
lot
of
infrastructure
and
just
get
rid
of
the
block
relay
now
so.
G
Yeah
and
and
4-0
we
have
that
like
when
a
block
comes
in
it
interrupts
processing,
so
that,
like
you,
can
you
can
get
them
locked,
move
it
along
and
matter
of
fact
it
does
so
pretty
sure
this
is
in
4-0
as
well.
It
actually
does
so
without
touching
the
main
thread
in
a
lot
of
cases,
so
it
can
actually
Shuffle
things
along
so
yeah.
G
We
certainly
would
like
you
to
like
try
to
see
whether
40
can
handle
that
without
a
dedicated,
lock,
relay
node
or
or
not,
and
if
not
you
know,
let
us
know
we
can
address
it.
One
thing
that
we
we
haven't
addressed
yet
and
we
actually
haven't
addressed
in
the
Bible
yet
either,
but
we
might
and
from
our
conversation
we
just
had
actually
makes
it
more
useful
So.
Currently,
what
happens
when
a
block
comes
in
is
that
we
will
schedule
it
to
be.
G
G
Then
currently,
that
is
the
highest
priority
thing
that
that
will
happen.
It
will
interrupt
anything
else
that
that's
happening.
That
wasn't
the
case
in
in
three
two
or
or
prior,
like
if
you
had
a
whole
bunch
of
unapplied
transaction
keys,
and
you
were
starting
to
block,
it-
would
actually
wait
until
a
full
block
tied
with
the
process,
the
law,
so
that's
been
thick.
What
we,
what
we
haven't
done
yet,
which
we
we
might
need
to
is
we
don't
actually
interrupt
a
transaction,
that's
currently
in
process.
G
So,
if
we're
specially
executing
a
transaction,
we
do
not
interrupt
it.
When
a
block
comes
in,
we
could
we
just
have
not
done
man
currently
the
Max
on
most
people's
known
since
30
milliseconds,
that
that
block
could
then
be
delayed
again
only
if
you
have
to
reach
into
the
main
thread
which
demonstration
belt,
but
in
the
cases
we
do,
it
does
wait
for
that.
That
transaction
to
complete.
G
So
we
have
not
made
that
change
even
in
the
Bible.
That
would
certainly
certainly
could,
but
what
even
without
it
like
that's
kind
of
a
corner
case
like
in
most
cases
we
can
process
the
block
immediately
without
touching
the
main
thread,
and
we
can
do
that
if
we're
in
sync.
Now,
if
the
note
is
a
block
or
two
behind,
we
actually
have
to
kind
of
schedule
it
a
bit
to
to
make
that
happen.
D
Yeah,
so
my
challenge
with
coming
up
with
that
analysis
is
well,
as
Ross
said
before
it's
hard
to
actually
do
these
things
on
a
test
net.
You
need
to
run
it
live
in
order
to
run
it
live.
We
need
the
other
block
producers
to
upgrade
the
4.0,
because
you
know
just
me,
upgrading
doesn't
help
I
need
to
see
how
it
reacts
on
the
network,
and
in
order
to
do
that,
then
we
need
the
fixes,
so
that
then
other
people
can
anyway,
so
we're
a
few
steps
that
we
need
to
accomplish
before.
D
So
I
think
you
know
if
we
can
start
doing
this
test.
Maybe
I
don't
know
at
this
point
looks
like
maybe
September
is
when
we'll
actually,
but
then
it's
too
late
to
make
any
changes
for
5.0,
because
it's
already
passed,
though
I
don't
know
so
anyway,
back
to
Brian's,
you
know:
how
can
we
do
things
better
from
a
scheduling
perspective
Maybe,
because
it's
you.
D
G
G
You
know,
I,
don't
know
what
we
can
say
there
I
mean
you
know:
we've
seen
to
not
done
a
great
job
there,
so
anyway,
we're
always
trying
to
improve
we're,
adding
new
tasks
for
for
all
these
that
are
coming
in,
but
yeah.
So
let
me
just
talk
about
the
right,
quick,
the
ones
I
know
about
that
have
been
logged.
So
currently
we
have
the
the
fact
that
we
can't
sync
us
from
Genesis
issue.
G
1354,
that's
been
evaluated,
I
know
what
the
bug
is:
it'll,
take
a
few
hours
to
fix,
and
so
we'll
get
that
done,
we'll
get
that
done
and
it'll
be
in
the
next
patch
release.
If
you're
curious,
it
has
to
do
with
our
our
beloved
deferred
transaction,
and
it
has
to
do
with
the
fact
whether
a
given
protocol
feature
has
been
activated
or
not
so
early
on
in
year
with
mainnet,
which
is
work
is
being
replayed.
G
Here
is
before
the
activation,
a
particular
protocol
feature,
and
we
broke
the
way
we
handled
that
protocol
feature
when
it's
not
enabled
because
yeah,
we
didn't
have
any
tests
for
that
before
those
those
blocks
that
had
that.
So
anyway,
it's
fairly
simple
fixed.
We
just
got
to
get
it
done,
and
and
in
there
it's
it's,
not
the
current
block.
I'm
working
I'll
work
that
next,
actually
what
I'm
currently
looking
at
is
a
report
from
cc3289,
which
is
a
problem
with
starting
up
a
ship.
G
Two
issues
reported
and
I
just
picked.
This
up,
I
haven't,
haven't
reproduced
it
yet,
but
the
first
issue
is
the
fact
that
you
don't
get
anything
from
ship
until,
if
you
don't
have
any
peers
connected,
that's
kind
of
like
understood,
like
I
kind
of
knew
it
worked.
That
way,
didn't
realize
that
that
this
was
a
use
case,
although
once
it
stated
out
loud,
it
seemed
kind
of
obvious
that
it's
it's
a
use
the
case
the
way
ship
Works
in
4-0.
G
Is
it
wakes
for
that
first
block
to
be
signaled
before
it?
It
does
its
thing.
It
did
that
to
kind
of
work
around
a
different
issue
with
the
way
like
snapshots
were
consumed
and
shipped
was
started
up.
It
kind
of
delayed
that
until
the
first
block
it's
it
is
received
with
our
printing
store
or
a
receipt
from
the
network.
G
The
the
use
case
here
is
that
you
actually
want
to
start
from
the
snapshot
consume
data
from
it
before
you
turn
on
any
peers
makes
sense
to
have
that
use
case.
It
just
doesn't
work
that
way.
So
anyway,
we
can
address
that
I,
hoping
that's
not
going
to
be
that
big
of
an
issue
that,
like
it's
all
bad
and
keep
the
other
solution
that
we
for
the
other
issue
we
had,
which
was
kind
of
a
startup
ship
error.
There
shouldn't
be
that
big,
a
deal.
G
The
other
thing
you
have
to
report
it
is
is
rather
strange
and
and
surprising
and
and
I'm,
not
sure.
What's
going
on
in
that
same
issue,
it
says
that
if
you
start
Chronicle
at
a
certain
block
number,
it
doesn't
receives
the
ABI
for
that
connection,
which
is
very
odd
and
I'm
surprised
like
if
that's
really
the
case
that
it
has.
G
Other
people
haven't
stumbled
upon
that
as
well,
so
I'm
not
sure
if
that's
somehow
related
to
not
having
a
pink
piece,
a
configured
there
or
what
anyway,
so
I
want
to
dig
into
that
figure
that
out,
so
that
that's
still
in
like
a
somewhat
like
trying
to
reproduce
and
see
what's
going
on
there
first
part
of
it
understood
yeah,
we'll
get
that
fixed,
the
other
part
I'm,
not
sure,
what's
going
on
there.
Okay,
then,
the
third
issue
that's
been
reported
is
some
weird
issue
with
that.
G
If
you're
connected
to
ship
and
then
you
disconnect,
it
somehow
affects
other
connections
the
ship
and
that
they
stop
receiving
data
and
so
yeah
that
that
still
is
actually
has
no
one's
actually
even
picked
it
up
or
take
a
look
at
it.
Yet.
So
it's
just
Dylan,
that's
where
we
are
I'm
actively
working
these
issues
right
now,.
D
G
G
It's
not
a
consensus
bug
at
all,
so
it
kind
of
edit
priority
went
immediately
down
and
got
chuckled
back
into
the
pile
room
and
and
yeah,
and
then
we
paid
that's.
Why
I'm
picking
up
number
two,
because
that
seems
a
higher
priority,
those
three
actually
and
and
the
first
one.
Again
it's
been
a
bug
since
three.