►
From YouTube: GraphQL Working Group - March 3, 2022
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
How's
it
going
it's
good
and,
in
seattle,
everything
all
right.
D
D
D
E
D
E
A
G
I'm
in
ottawa,
canada,
so
yeah,
surrounded
by
lots
of
snow
we've,
had
a
lot
of
snow
over
the
past
couple
weeks
in
particular,
so.
G
F
A
G
H
G
I
K
G
K
Let
me
see
if
I
have
any
other
pull
requests
open.
I
don't
think
that
I
do.
K
Please
lee
jeez
there
I
go
again
yup,
I'm
I'm
gonna
get
you
some
live
notes.
K
I
really
I've
got
no
no
excuse
this
time,
because
I
literally
put
something
in
my
calendar
that
says:
review
agenda
add
note
stock
and
I
reviewed
pull
requests
instead,
so
there
you
go.
K
K
I
don't
know
if
you
guys
saw
this.
I
wrote
a
tweet
a
couple
days
ago:
graphql
turned
10
years
old.
How
crazy
is
that.
K
Yeah,
obviously
not
all
of
that
has
been
open
source.
It's
a
significant
part
has
been
open
source.
K
B
K
K
K
I
will
share
that
in
the
chat
too.
Just
so
you
don't
have
to.
K
All
right.
We
have
a
fair
amount
of
stuff
to
talk
about
today
as
well,
so
let's
get
into
it
sorry
again
for
being
a
little
bit
late,
all
right
to
kick
us
off
by
being
here.
We
all
agree
to
our
membership
agreement,
participation,
guidelines,
contribution
guide
and
code
of
conduct
links
in
the
agenda
as
per
usual
in
case
you
ever
want
to
click
review
over
those
guide,
in
particular
pretty
great
duck.
K
Some
of
those
other
ones
are
a
little
more
legal
mumbo
jumbo
contribution
guide.
I'm
proud
of
that
one
anyhow:
let's
do
a
quick
round
of
introduce
introductions
names
to
faces
for
all
the
folks
in
the
room
here
and
then
we'll
go
over
our
agenda.
K
J
Alex
you
here,
yep
sorry,
I
was
muted
yeah
yeah,
I'm
alex.
L
N
O
Q
H
Hey
everyone:
my
name
is
kelvin
century's
racing,
anthony
first
working
group
meeting
and
I'm
his
counterpart
on
the
team
so
happy
to
meet
you
all.
K
I
think
he
got
everybody
and
then
I
also
want
to
acknowledge
that
yvonne
is
not
here
today.
I
did
I
checked
in
with
him
earlier.
He
says
that
he's
okay,
obviously
some
crazy
going
on
in
his
hometown,
but
he's
in
la
viv,
which
is
more
one
of
the
more
safer
cities.
I
don't
know
if
you
could
call
any
of
the
cities
they're
safe
at
the
moment,
but
he's
pretty
close
to
poland
and
he
says,
he's
doing
all
right,
but
not
able
to
come
today.
K
Unfortunately,
but
I'll
keep
checking
on
him.
G
No,
but
the
really
good
news
he
did
get
the
rest
of
his
family
out
of
the
bad
parts
of
ukraine,
so
they're,
actually
all
on
the
way
to
him
right
now,
which
is
great
to
hear.
K
K
Okay,
let's
take
a
quick
look
at
our
agenda.
We'll
do
a
quick
look
at
through
our
past
action
items
see
if
we've
got
anything
that
we
can
close
out
or
that
needs
discussion.
There
client
controlled
nullability.
We've
got
a
lot
of
stuff
to
talk
about
here,
fantastic
deferring
stream,
update
from
rob
and
then
a
little
bit
of
a
discussion
on
graphical
lead
maintainers.
K
I
actually
that'll
be
an
interesting
discussion
as
well.
Anything!
That's
not
here
that
we
should
talk
about.
K
K
Maybe
we
can
just
look
at
some
of
these
most
recent
ones
to
see
if
any
of
these
need
something
new
from
us
or
can
be
closed
out,
maybe
it'll
be
helpful.
If
I
share
my
screen
really
quick.
K
All
right,
can
you
guys
see
my
my
browser
cool
okay,
so
we'll
just
go
through
these
together?
Really
quick
review
default
value,
quotient,
spec
text
alignment
report,
brush
implementation,
okay,
this
one's
still
on
me.
That's
just
a
final
review.
E
There's
an
initial
implementation
which
looks
good
from
a
quick
scan,
but
I
haven't
had
time
to
actually
do
a
deep
review
of
it.
Yet,
okay.
K
We
will
leave
this
open
so
that
we
don't
forget
about
it,
then,
but
that's
awesome
to
see
progress
and
this
next
one
raise
a
pr
for
preventing,
skip
and
include
on
a
subscription.
K
E
K
E
I've
already
written
the
spec
pull
request,
yeah
it's
linked
there.
It's
just,
we
haven't
implemented
it
from
what
I
recall
of
graphql.js-
and
this
is
this-
was
back
in
the
15
branch,
because
I've
not
had
a
chance
to
work
on
it
for
a
while
there's
a
lot
of
oddities
in
the
way
that
graphql
js
is
validating
the
subscription
stuff.
E
E
K
I
think
I
I'm
remembering
now
our
past
discussion
that
was
around
this
this
proposal
and
a
desire
to
make
it
not
complicated
in
that
way
to
find
the
simpler
solution
that
got
the
same
end
result.
Yeah.
E
B
At
the
moment,
it
does
special
validation
logic
so
to
essentially
find
out
if
something,
if
a
subscription
is
skipped
or
what
do
they
do
at
the
moment,.
E
So
what
it
does
is
because
it
has
to
do
it.
Does
the
field
collection
to
find
out
that
there's
only
one
field
and
it
does
it
respecting,
skip
and
include,
but
obviously
it's
done
during
validation,
so
it
doesn't
actually
have
access
to
the
variables.
So
it's
done
using
skip
and
include
just
assuming
that
none
of
the
variables
are
present,
even
if
the
variables
are
required.
E
So
there's
yeah,
there's
some
weird
complexity.
There's
some
weird
things
going
on.
K
Oh,
I
see
what
you're
saying
yeah
that
there's
the
validation
rule
that
says
you
have
one
field
and
then
that
validation
rule
has
to
right
now
fake
an
execution
context,
which
is
something
that
ideally.
K
There's
one
field
we
want
to
say
I
have
some
simpler
version
of
doing
that
that
we're
not
requiring.
B
E
Possible
with
subscriptions
yeah,
you
can
have
fragments
on
subscriptions
as
well,
and
that
is
part
again
of
where
graphql
js
handles
that
specific
case
in
subscriptions
in
a
very
weird
way.
I
remember
so
from
a
simple
point
of
view:
if
we
just
forbid
skip
and
include
directives
at
that
level,
specifically
on
that
one
selection
set
and
any
fragments
that
are
spread
in
it,
then
we
get
rid
of
the
problem.
E
Basically
it
it
doesn't
actually
cause
like
it's
not
a
vulnerability
or
anything
like
that,
because
we
we
re-validate
during
execution
that
there
was
one
field
after
the
collect
fields.
So
it
is
checked,
but
it
kind
of
it
allows
things
through
validation
that
are
not
necessarily
or
can
be
seen
that
they
are
likely
to
be
invalid.
Later
it
just
doesn't
it
just
doesn't
really
make
sense,
and
I
don't
think
there's
any
need
for
skipping
included
at
that
point.
It
just
doesn't
really
make
sense.
K
Right,
okay!
Well,
if
anyone
is
so
motivated
to
pick
this
up,
I
think
it
will
be
good
for
us
to.
I
know
this
one
has
not
been
the
most
urgent
rfc,
but
it's
also
not
necessarily
the
most
complicated.
So
if
anyone's
motivated
to
make
some
action
on
this,
I
think
that
would
be
good.
K
Okay,
I'm
not
going
to
go
too
far
down
this
list.
I
think
there's
a
handful
from
november
that
are
everyone
review,
so
maybe
just
a
quick
reminder
that
there's
a
couple
prs
and
rfcs
that
could
use
some
feedback
projects
yeah.
Okay,
we've
got
a
handful
of
them
that
are
still
quite
old,
but
I
think
we
need
to
dive
too
deep
into
that
for
now
all
right,
I'm
gonna
stop
sharing
and
we
can
move
on
alex.
I
can
hand
it
to
you.
J
Already
I'm
gonna
screen
share,
put
together
a
little
little
thing
for
this.
I
think
y'all
are
gonna,
see
my
speaker,
notes
and
know
that
you
know
magic,
isn't
real
and
it's
all
scripted.
J
Okay,
cool
yeah,
so
in
since
the
past
meeting
yvonne
was
able
to
get
out
get
out
canary
releases,
they're
working
they're
working
great.
They
get
released
on
npm.
You
can
use
them
today.
If
you
want-
and
I
started
integrating
into
apollo's
client
they've
been
kind
enough
to
help
me
to
get
something
together,
that
they
could
possibly
release
in
their
1.0
release.
We're
working
out
the
details
still
but
been
very
helpful,
and
I
have
test
passing
and
it's
generating
the
code.
I
would
expect
with
with
the
current
implementation.
J
Before
I
get
too
deep
into
it,
though,
I
want
to
make
sure
that
we
have
a
set
of
behaviors
on
client,
controlled
nullability
that
people
can
be
confident
in
so
we're
going
to
do
today
is
try
to
reach
some
level
of
consensus
on
the
broad
strokes
of
the
proposal.
What
we
decide
will
be
implemented
in
graphql,
js
and
used
for
experimental
releases
of
clients
and
servers
that
choose
to
support
client,
controlled
mobility.
J
We're
gonna
do
a
brief
overview
of
the
proposal
for
people
who
aren't
familiar
we're
gonna
review
the
current
positions
of
the
working
group
members
who
have
participated
in
the
client
control
nobility
discussions
we're
going
to
go
over
the
goals
of
this
discussion
and
then
we're
going
to
present
on
each
of
the
you
know
the
discussions
that
have
been
posted
go
through
each
behavior
talk
about
I'll,
go
over
the
structure
that
in
a
bit
and
then
once
we
have
a
set
of
things
that
make
sense,
we
can
go
on
the
next
steps.
J
If
this
goes
too
long,
we
can
wait
for
the
next
one
too,
but
I'm
hoping
to
get
through
it
today.
So
a
real,
quick,
brief
overview
of
what
this
is
client
controlled
nullability
is
a
proposal
to
add
syntax
to
the
query
language
that
allows
us
to
say
something
to
the
effect
of.
I
know
that
this
field
may
come
back
null
if
it
comes
back
null,
it
does
not
work
for
my
feature.
My
view
won't
render.
My
component
doesn't
work,
something
something
like
that.
J
So
I
want
to
treat
this
like.
It
is
non-nullable,
that's
useful
for
us
when
we're
doing
a
code
generation,
it
makes
it
clearer
what
the
person
writing
these
queries
wants
out
of
them
and
the
the
main
driver
of
this
is
people
at
yelp,
where
I
work,
one
of
their
main
usability
complaints
was
that
they
had
to
write
wrappers
and
unwrap
each
individual
field
to
make
sure
it
wasn't
null
before
this.
This
stuff
was
usable.
J
I've
written
up
a
document.
I
will
link
it
in
the
chat.
Where
is
the
chat?
Oh
there's,
the
chat,
I
went
through
all
past
discussions
and
tried
to
figure
out
what
individual
people's
positions
are.
So
if
you
want
to
find
yourself
in
this
list-
and
you
know
verify
that
what
I've
written
here
is
still
your
your
actual
positions
on
things,
you
can
feel
free,
everybody
should
have
edit
rights,
so
you
can
feel
free
to
update
these
as
we
go.
J
It'll
help
me
guide
discussion
and
you
know
talk
to
people
about
this
stuff
later.
If
there's
still
certain
concerns,
so
it'll
be
helpful.
For
me,
where
is
where's
the
link
to
that?
I
just
sent
it
to
the
zoom
chat,
got
it
cool?
J
Okay
cool,
so
the
goal
of
today
is
not
to
find
the
behavior
for
client
control
of
null
ability
that
everybody
loves,
but
to
find
the
behavior
that
will
work
for
the
most
people.
Your
favorite
behavior
might
not
be
picked
for
development,
but
the
aim
is
to
avoid
picking
behavior
that
doesn't
work
for
your
use
case,
because
of
that
we're
going
to
focus.
J
Okay,
sorry
vs
code
was
asking
for
permissions
for
some
reason
because
of
that
we're
going
to
focus
discussion
primarily
on
critiques
and
each
discussion,
we'll
start
by
asking.
If
any
of
the
options
on
the
table
are
hard
blockers,
I'm
not
asking
if
you
dislike
any
of
the
options,
I'm
asking,
if
any
of
the
options
will
cause
you
or
your
users
to
be
unable
to
use
client
control
modability,
I'm
hoping
that
by
doing
this,
we
can
temporarily
end
discussion
on
unpopular
options.
J
J
So
I'd
be
great
if
we
can
abandon
some
of
them
if
the
feedback
is
poor
after
the
experimental
release
releases
have
been
in
production
for
a
while,
then
we
can
reassess,
but
at
least
then
we'll
have
some
concrete
experiences
to
work
from,
and,
lastly,
I'd
like
to
feel
people
to
feel
like
the
experimental
releases,
client,
controlled,
nullability
aren't
based
on
unilateral
decisions
that
I've
made.
J
I
want
people
to
feel
like
they've,
had
the
opportunity
to
be
part
of
the
decision
making
process
and
I'm
hoping
that
this
creates
some
confidence
in
what
gets
released
so
now
we're
going
to
go
into
each
of
the
behaviors
I'm
going
to
tightly
control
the
time
that
people
speak
on
this.
So
if
I
cut
you
off,
I'm
sorry
but
we're
going
to
try
to
get
through
a
lot
here.
J
So
it's
decided
pretty
early
on
that.
We
want
to
be
able
to
control
the
nullability
of
elements
within
a
list.
In
addition
to
the
list
itself,
the
following
are
the
proposed
syntax
options.
J
The
first
is
this
bracket
syntax.
Where
list
depth
is
defined
by
a
number
of
brackets
in
the
syntax.
Can
everybody
read
this
by
the
way?
Is
it
big
enough?
I
don't
yeah
cool
yeah,
so
there's
this
bracket,
syntax
that
defines
the
depth
and
then
we
put
the
client
control
nullability
operators
at
various
levels
in
the
list
depth
there's
the
sequence
of
modifiers.
J
This
can
be
applied
from
the
outside
in
or
the
inside
out
on
a
list,
and
we
have
the
arrow
or
as
syntax
that
we
can
decide
on
specifically
what
we
want,
but
this
one
would
involve
basically
restating
the
type
of
the
field.
This
one
would
change,
non-list,
syntax
in
addition
to
list
syntax.
J
So
real
quick,
I
want
to
try
to
save
us
a
little
bit
of
time.
We
have
a
public
vote
where
the
bracket
syntax
has
more
votes
than
all
other
options,
combined,
there's
nearly
40
votes
here,
it's
enough
that
I'm
comfortable
deciding
on
something
and
avoiding
discussion.
So
I
want
to
see
if
anyone,
if
anyone
would
object
to
ending
discussion
and
going
with
the
bracket,
syntax
and
moving
on
to
the
next
behavior
or
if
any
of
these
options
are
going
to
be
hard
blockers
for
you
or
your
use
case.
O
I
think
in
the
voting
we
didn't
have
the
option
to
say:
don't
worry
about
inner
lists
in
our
list
items.
Oh
okay,
so
that
that's
the
only
like,
I
think,
the
actual
syntax.
I
don't
particularly
care,
but
I
think
the
question
of
do
it
or
not,
and
have
that
be
a
blocker
for
the
rest
of
the
nullability
project
is
the
real
question
in.
R
K
I
think
yeah
we
should
hold
that
as
a
backup
unless,
if
we,
if,
if
there
isn't
good
consensus
here
like
if
we
feel
like
we
haven't
cracked
this
one,
it's
always
reasonable
like
we,
don't
it's
not
that
painful
to
set
down
this
problem
come
back
to
it
later.
If
we
had
to,
but
I'm
kind
of
with
alex
it
seems
like
you've
got.
K
I
think
you
my
opinion
here
is
you
could
pretty
easily
rule
out
the
middle
two
options
just
because
just
the
fact
that
they're
easily
confused
with
one
another
seems
like
a
plainly
obvious
reason
to
disqualify
them.
I
know
some
people
voted
for
them,
so
I
don't
know.
Maybe
that's
slightly
controversial.
You
can.
Let
me
know
if
I'm
far
off
there,
but
my
senses
we're
really
looking
at
the
top
and
the
bottom
one
in
which
case
feels
stylistic
to
me
more
so
than
anything
else.
I
don't
know
I
like
your
pitch
alex.
E
I
have
one
one
question
which
is:
if
the:
if
the
top
one
is
an
option,
is,
is
valid
on
something.
Would
it
also
be
valid
to
just
have
the
question
mark.
J
K
K
J
That's
what
I'm
going
for
the
ones
that
the
discussions
we
have
here
are
they'll
like
their
their
impact
on
the
way
this
works
and
the
way
it's
implemented
are
pretty
broad
like.
If
we
go
with
with
some
of
the
null
propagation
options,
then
I'm
gonna
have
to
change
the
implementation
pretty
dramatically,
so
I'm
I'm
mostly
interested
in
in
like
yeah.
Can
we
can
we
pick
one?
J
We
can
figure
out
the
details
later,
but
if
we
can
discount
a
few
of
them
cool
great
I'll
go
in
it
sounds
like
people
kind
of
want
to
discuss
this.
Is
there
more
people
want
to
say
I'm
going
to
start
a
timer
just
to
keep
track
of
these
things?
Yeah.
A
I
would
I
would
vote
for
number
four,
the
last
one
it
looks
like
we
are
overriding
type.
It
will
be
much
more
clear
if
we,
even
if
it's
a
repeat-
and
it's
implied
that
it's
int
there,
then
just
it-
should
represent
a
client
controlled
type
sort
of,
and
it
should
look
like
a
type
decoration,
not
just
this
squiggly
wiggly
brackets,
but
this
implies.
You
could
also
change
the
type,
but
no
it
doesn't
it
can
be.
A
It
can
be,
but
some
repeat,
some
redundancy
is
often
helpful
and
from
the
point
of
view
of
the
server
for
me,
for
example,
it's
much
easier
to
have.
You
know
it
will
be
the
same
parsing
you
know
function
for
a
normal
type
declaration,
or
this
in
this
case.
K
And
just
want
to
point
out
a
couple
things.
One
is
last
time
we
talked
about
this.
We
identified
that
the
syntax
you're
seeing
on
the
screen
here
is
the
extreme
corner
case
that
we
should
expect
95
percent
of
use
cases
to
not
even
address
listen,
all
ability
syntax
in
the
first
place,
and
for
those
that
do
it
will
be
exceptionally
rare
to
go
more
than
one
level
deep
that
that's
really
the
syntax
we
should
be
looking
at
is
one
level
deep.
K
But
I
do
want
to
point
out
alex
to
your
point
about
specifically,
rather
than
looking
for
preferences.
Looking
for
constraints,
the
this
fourth
option
would
introduce
a
new
way
in
which
a
query
could
be
broken,
because
this
would
require
the
type
listed
in
the
query
and
the
type
in
the
schema
to
match,
and
there
are
cases
where
the
type
name
in
the
schema
may
change.
That
today
would
be
risky,
but
not
necessarily
breaking,
and
this
would
expand
the
surface
area
where
that
could
break,
and
I
think
we
should
hold
as
a.
K
J
That,
along
with
I,
I
do
think
this
looks
like
a
like
a
type
cast.
This
is
syntax,
that's
used
in
other
languages
for
typecast
and
the
having
the
type
in
there
yeah
it
currently
doesn't
really
have
any
actual
impact
other
than
the
fact
that
it
can
break.
B
That's
that's
my
my
issue
also
with
it.
It
looks
like
a
typecast,
but
it
is
not
a
typecast
and
we
are
encoding
the
type
in
the
query,
whereas
you
could
like
introduce
start
within
on
the
back
end
and
maybe
have
a
named
version
of
in
later.
That
is
a
semantical
end
and
it
wouldn't
break
your
query.
J
Oh
anything
else.
E
So
yeah
what
lee
said
just
now
was
basically
we
won't
have
to
worry
about
this
in
in
the
majority
of
cases,
but
that
doesn't
seem
to
mesh
with
what
you
said
just
now,
alex
that
the
depth
does
have
to
match.
So
if
you
have
a
list
field,
you
have
to
specify
square
brackets,
exclamation
point
close
square
brackets
exclamation
point
and
I
think
for
many
people
they
might
just
want
to
add
exclamation
point
or
question
mark
and
not
have
to
worry
about
the
list
depth.
E
However,
if
we're
going
to
allow
that,
then
that's
where
the
same
kind
of
ambiguity
comes
in
that
the
middle
two
options
have.
If
you
have
a
list
field-
and
you
only
add
an
exclamation
point
to
it,
are
you
making
the
inside
or
the
outside
of
it?
You
know
the
the
exclamation
point,
so
it's
got
the
exact
same
problem
unless
you
do
enforce
the
list,
steps,
in
which
case
we're
always
having
to
put
the
square
brackets
on
any
list
field
which
is
less
than
desirable
but
acceptable.
J
Yeah,
it
would
be
any
list
field
that
is
altering
its
nullability
of
of
the
field
itself
for
its
elements.
So
a
a
list
field
where
you're
not
using
client
controlled
nullability
would
not
need
the
square
brackets.
J
I've
gone
with
sort
of
the
the
strictest
implementation
for
a
lot
of
these
options.
Just
because
I
want
to
start
there
and
then
we
can
loosen
things
but
yeah.
I
see
what
I
see
what
you're
you're
saying
benji
for
sure.
K
I
don't
I
don't
know
if
I
love
that
it's
the
specific
iteration
that
we
have
for
this
right
now.
That's
why
I
wanted
to
make
sure
that
we
could
split
this
into
two
two
decisions.
One
decision
is:
do
we
want
to
narrow
this
down
to
one
branch
to
go
explore
and
the
second
decision
which
it
sounds
like
we've
got
more
room
to
figure
out,
is:
do
we
have
the
right
point
within
that
branch
at
present
and
we
might
not
yet
yeah
yep.
J
Cool
for
about
a
time
I'm
gonna
move
to
a
vote.
In
order
to
vote,
please
write
which
option
you
would
like
in
the
chat
if
you're
submitting
proxy
votes,
I've
allowed
people
who
have
already
participated
in
discussion
to
submit
votes
through
other
people
in
their
org.
If
you're
doing
that,
please
submit
it
through
the
chat
and
then
we'll
tell
him.
E
That
would
be
ideal.
Yes,.
J
Cool
it
looks
like
option
one
has
it.
Q
K
I
think,
we're
mostly
in
agreement
that
that
top
option
is
the
one
that
we'd
like
to
explore
instead
of
the
other
three,
but
we
still
need
to
make
sure
that
it
is
there's
some
variability
in
that
design
space
as
well,
and
if
we
can't
find
one
that
works,
then
to
the
point
earlier.
I
think
it's
it's
not
completely
unreasonable
that
we
like
scope
it
out
of
the
proposal
for
the
short
term
yeah.
I.
Q
I
understand
the
complications
there.
I
think
that
the
one
thing
I
just
want
to
say
is
that
I
feel
strongly
that
this
nullity
syntax
is
an
important
part
of
this
feature
to
actually
fulfill
the
intentions
of
it
for
client
projects,
and
I
don't
actually
care
what
we
choose
as
the
syntax,
but
I
just
feel
strongly
that
we
should
include
this
list
nullability
next.
K
Okay,
I'm
with
you,
I
think
it's
it'd
be
it'd,
be
hard
to
explain
what
we're
up
to
like.
I
can
imagine
people
immediately
having
the
question
of
like
wait.
What
about
this
one
specific
case
where
I
have
a
list
of
things
so
yeah.
That's
definitely
part
of
the
result.
We're
talking
about
it.
I.
J
I
haven't
heard
a
strong
objection
to
having
the
syntax
in
the
thing.
Yet
if
there
is
one
yeah
I
don't
know
we
can
talk
about
it
afterwards.
Maybe
maybe
it
exists,
but
I
haven't
heard
it
yet.
So
I'm
gonna
proceed
with
putting
putting
it
in
using
the
bracket.
Syntax
yeah.
K
I
think
alex
the
way
you'd
want
to
think
about.
This
is
if
all
of
your
other
threads
have
resolved,
and
and
this
list
one
is
the
last
one
going
and
you're
like
man.
If
only
if
only
I
didn't
have
to
deal
with
that
list,
syntax
thing,
then
we
could
just
ship
this
like.
That
would
be
the
mode
when
you'd
want
to
make
it
a
serious
consideration
about
whether
to
cut
it
loose
or
close
to
that,
though,.
J
J
This
is
up
for
discussion,
because
people
have
some
concerns
about
accidentally,
wiping
out
a
child
or
sibling
or
parent
fields
when
something
comes
back
null,
even
if
you
expect
to
come
back
and
all
when
you're
prepared
to
handle
it
specifically,
if
you're
using
a
lot
of
fragments
they're
you
they're
you're
at
risk
of
wiping
out
fields
that
maybe
you
did
not
intend
to
so
we
got
three
options
here.
J
The
first
one
is
that
the
non-nullable
designator
acts
like
non-nullable
in
sdl
fields,
are
marked
with
an
exclamation
point
or
treated
exactly
like
non-nullable
schema
fields.
If
null
is
found
for
one
of
those
fields,
then
it
propagates
to
the
nearest
nullable
parent.
I
got
some
examples
yep.
So
here
we
have
our
our
schema
we
have
istart
is
marked.
J
Okay,
we
have
a
non-destructive
non-nullable
this
and
this
one
the
required
designator,
does
not
change
the
content
of
the
data
field.
It
only
exists
to
provide
information
to
graphql
clients.
They
can
choose
what
to
do
when
a
field
is
marked
with
an
unknowable
designator.
When
it
comes
back
null
client
behavior
is
likely
to
differ,
but
this
flexibility
can
be
seen
as
a
positive
or
a
negative.
J
Then
we
have
null
propagates
to
nearest
question
mark
jordan.
Would
you
mind
talking
about
this
one,
and
why
why
you
think
it
might
be
good
for
relay.
P
I
was
trying
to
bring
this
one
back
on
the
table
is
that
in
relay
we
have
two
flavors
of
that
required
directive,
one
which
acts
basically
like
a
the
schema
bubbling,
where
just
bubbles
to
the
nearest
parent,
if
it
if
it
becomes
null
or
the
nearest
nullable
parent
and
one
which
throws
so
it
it
blows
up
the
whole
component.
P
Far
and
away
most
people
are
choosing
the
throw
option.
This
is
influenced
a
bit
by
the
error,
boundary
concepts
that
react
has
where
throwing
can
be
like
the
blast.
Radius
of
an
individual
throw
can
be
relatively
contained
within
a
an
application,
but
just
the
fact
that
about
like
90
or
more
of
our
usage
is
specifying
this
more
destructive
behavior,
where
it
says
like
look.
If
this
field
is
missing,
I
really
can't
do
anything
here
and
I
don't
I
don't
intend
to
recover.
I
intend
to
sort
of
blow
up.
P
It
also
made
me
wonder
whether
other
clients
or
users
of
other
clients
would
want
a
similar
behavior
to
what
relay
throw
option
is
given
that
that's
far
and
away
what
most
people
choose
in
relay.
But
that
may
be
again
flavored
by
react's
error,
handling,
cinematics.
O
Another
point
on
this,
just
to
kind
of
is
a
little
bit
of
history
is
originally
we
were
expecting
for
relay
for
the
null.
Basically,
the
null
propagation
like
treating
it
like
a
non-nullable
to
be
the
vast
majority
of
usages,
and
we
were
surprised
by
what
product
developers
actually
chose
to
do
in
practice.
J
Great
thank
you
appreciate
that
we're
going
to
move
to
discussion
now.
These
are
the
discussion
options
I'm
going
to
start
by
asking
if
any
of
the
options
on
the
table
are
no-gos
hard
blockers
for
you
or
your
use
case,.
E
J
Right
so
this
would
change
only
the
par
step
of
of
the
of
you
know:
graphql
the
graphql
implementation.
It
would
do
nothing
to
execution
execution
would
happen
as
normal.
Basically,.
Q
Servers
wouldn't
actually
care
about
the
exclamation
point.
Modifier
clients
would
have
to
handle
it
themselves
and
if
they
know
that
the
client
control
vulnerability
is
using
the
exclamation
point,
then
they
have
to
manually
during
their
validation
of
a
response
check
that
field.
If
it's
null
then
do
some
handling
themselves
and
throw
an
error
instead
of
giving
a
response,
object
or
something.
J
Yeah,
this
also
gives
them
enough
information
in
order
to
code
jen.
This
is
the
sort
of
thing
that
we're
looking
for
with
this
yeah.
Q
One
one
thing
I'd
like
to
mention
about
this
is:
if
we
went
with
a
non-destructive
or
even
if
we
don't
go
with
this
option,
clients
could
implement
what
I
just
said,
which
is
you
know,
checking
for
the
know,
fields
themselves
if
they
have
a
non-destructive
or
an
exclamation
point,
so
that
they
are
backwards,
compatibili
compatible
with
servers
that
don't
implement
or
have
not
yet
implemented
ccn.
P
Q
P
That's
a
really
important
point
because
I
think
basically,
any
client
that
has
a
normalized
store
that
is
shared
across
multiple
queries
would
need
to
compile
this
away
and
handle
it
on
the
client,
because
when
a
a
server
response
comes
back
and
it's
missing
data,
the
the
sort
of
source
of
truth
in
the
normalized
store
couldn't
necessarily
be
reconstructed.
P
B
Q
Yeah,
I'm
not.
Actually,
I
don't
propose
that
we
take
option
two,
as
the
as
the
suggestion
says,
the
solution,
but
even
if
we
do
one
of
the
others
where
client,
where
servers
do
their
own
validation
of
this,
I
think
that,
like
jordan,
said,
clients
are
still
gonna
have
to
do
the
validation
again,
whether
or
not.
B
K
Yeah,
technically,
you
could
do
this
now,
except
that
then
you'd
be
on
the
hook
for
having
a
variant
of
graphql
to
parse
and
feed
to
other
tools,
but
I
think,
back
in
the
day,
relay
even
kind
of
considered
doing
this
kind
of
variant
and
decided
not
to
in
favor
of
directives.
But
this
I
think
this
option
too,
is
just
hey.
What?
B
E
O
P
Similarly,
with
the
the
point
I
was
talking
about,
normalized
stores
right,
like
different
responses,
you
share
the
server
the
the
normalized
story
having
to
represent
the
source
of
truth
on
the
server,
not
the
source
of
truth,
that's
observed
by
a
single
query,
so
I
think
this
keeps
coming
back
to
like
the
the
global
best
outcome.
Is
we
solve
fragment
isolation,
and
then
we
can
do
the
null
propagates,
the
nearest
question
mark
without
it
being
a
terrible
foot
gun,
but
that
is
like
a
very
like
that
means.
P
P
K
O
Yeah,
I'm
not
100
confident
that
it
is
a
huge
foot
gun
given.
We
do
already
have
global
validation
that,
like
fields
like
when
fields
when
we
merge
fields
that
they
don't
have
overlap
like
that
is
itself
a
foot
gun
but
like
we
handle
it.
So
I'm
not
convinced
that
the
question
mark
propagation
is
as
big
a
foot
gun
in
practice,
especially
given.
Most
queries
are
probably
relatively
small,
like
within
facebook,
where
we
have
queries
with
thousands
of
fragments
on
them.
Yeah
it
sucks,
but
I
don't
think
that's
normal.
B
B
J
So
there's
a
little
bit
of
nuance
so
propagating
to
the
next
nullable
field
will
stop
if
there
is
a
nullable
field
in
between
the
just
like
if
the
next,
if
the
parent
of
something
marked
with
an
exclamation
point
is
nullable,
it
will
stop
there
with
the
propagate
to
nearest
question
mark.
It
will
go
all
the
way
through
everything
between
the
exclamation
point
and
the
question
mark
will
be
blown
out
if
the
exclamation
point
is
null.
P
K
P
Case
is
in
the
query,
so
it's
the
it's.
The
next
client
controlled
nullable,
explicitly
noble
field.
K
K
K
It's
not
just
it's
not
that,
like
hey,
oh,
you
got
a
null
like
we're.
Gonna
go
propagate
this
air,
it's
like
no!
Actually
there
was
this.
There
was
data
invalid
data
tried
to
come
through
and
you
have
to
kind
of
panic
at
that
point
and
bubble
up
until
you
get
to
the
you
know,
least
breakable
point,
and
the
client
is
unaware
of
that
entire
situation.
That
is
that's
entirely
the
server's
domain
and
the
goal
should
be
to
have
a
server
that
never
creates
exceptions
that
you
know.
K
We
measure
that
in
nines,
rather
than
being
able
to
provably,
say
that
you
can
never
have
your
server
break,
but
this
is
meaningfully
different
like
when
you
put
an
exclamation
point.
K
If
a
field
says
that
it
is
nullable
and
you
put
an
exclamation
point,
there
you're
saying
that,
there's
times
when
the
server
has
very
real
data
output,
that
I
want
to
say
that
I
wanted
to
create
different
behavior
for,
and
I
think
that's
actually
pretty
different
from
the
server
produced
error
construction,
and
when
doing
that,
I
think
we
need
an
equivalent
way
to
then
handle
that
so,
and
I
think
this
is
part
of
the
reason
why
the
relay
team,
upon
rolling
out
this
feature
via
directive
and
offering
basically
both
of
these
behaviors,
found
that
people
preferred
the
latter.
K
One
is
the
latter.
One
gives
you
control
over
the
end
result
where
the
first
one
doesn't.
The
first
one
just
says
we're
going
to
slurp
up
the
error
at
the
next
most
level,
but
that
might
not
be
the
thing
you
want
and
either
you
would
have
to
like
put
exclamation
points
all
the
way
along
the
path.
All
the
way.
K
To
the
point
where
you'd
want
to
have
that
question
mark-
or
we
we
used
this
last
one
to
say
anything
where
you
where
the
client
says
I
want
to
create
separate
behavior
here,
the
client
must
also
say,
and
then
I
want,
like
the
other
end
of
that
behavior
happens
here.
I
am
curious
to
learn
more
about
the
idea
that
this
could
be
a
foot
gun.
K
Q
Does
this
last
option
fix
the
fragment
isolation
issue
or
the
issue
of
a
merged
non-null
field
being
propagated
from
one
fragment
and
there's
other
fragments
that
are
used
in
the
same
field,
and
don't
have
that
exclamation
point
I'm
still
struggling
with
how
that
should
be
addressed.
P
It
does
not,
but
it
does
preserve
the
option,
value
that
if,
when
we
do
have
name
fragments,
we
could
make
fragment
boundaries,
an
implicit
question
mark,
and
so
you
would
blow
up
to
the
fragment
boundaries
or
we
could
have
some
syntax
to
allow
you
to
do
that.
So
it's
not
that
it.
It
potentially
aids
in
it
in
the
in
the
short
term,
but
it
does
offer
a
sort
of
global
maximum
of
x,
assuming
we
can
solve
both
problems.
I
see.
E
O
K
Client
can
I
frame
that
the
two
potential,
because
the
or
the
the
foot
gun
space,
my
understanding
is
that
there's
two
distinct
potential
foot
guns
and
I
want
to
just
reframe
them
and-
and
let
me
know
if
I'm
mischaracterizing
these
or
if
there's
one,
that
I'm
missing
so
one
foot
gun,
is
along
the
lines
of
field
merging
and
fragment
boundaries,
and
this
idea
that
if
you
encounter
the
same
field
along,
you
know
two
paths
of
spreading
in
fragments
right
now
or
the
behavior
of
this
proposal
says
those
have
to
have
the
same
client
controlled,
nullability
flags
on
them.
K
Otherwise
they
won't
merge
to
just
to
avoid
the
situation
where
you
know
one
is
required
and
one
is
an
air
boundary
or
something
confusing.
We
don't
know
how
to
interpret
it.
That
is
a
potential
foot
gun
where,
if
you
try
to
mark
something,
as
required
with
an
exclamation
point,
that
could
produce
a
a
an
invalidation
error
that
you
then
have
to
go
chase
down
all
the
various
other
places
where
that
thing
occurs
to
get
them
to
match.
K
That's
one,
the
other
one.
Is
this
idea
of
exclamation
point
and
question
marks
probably
needing
to
show
up
as
pairs,
and
maybe
this
one
is
a
documentation
problem
like
helping
people
understand
what
is
the
behavior?
That
will
happen
when
something
occurs
here?
K
K
E
Use
different
symbols
like
if
we
were
to
go
with
option
three,
it
doesn't
have
to
be
exclamation
point
and
question
mark
if
that
isn't
clear
to
people
what
it
means.
K
A
A
J
Like
to
try
to
not
discuss,
naming
or
or
different
syntax
right
now,
I'm
trying
to
get
like
like
concrete
behavior
down.
We
can
talk
about
different
syntax
once
you
decide
on
something
but
yeah,
I'm
just
what
I'm
trying
to
vote
on
right
now.
Are
people
comfortable
going
to
a
vote,
yep
cool,
excellent,
there's!
There's
your
options.
Put
your
I'm
gonna!
Wait!
I'm
gonna
make
a
divider,
so
I
don't
cat
cool.
Oh
someone
did
it
for
me
excellent.
J
All
righty
voting.
J
For
the
people
that
are
saying
one
or
the
other,
can
I
ask
that
you
pick
your
favorite?
I
don't
know
how
to
how
to
tally
that
up.
Just
just
don't
tally.
J
G
Does
that
become
two
if
it's
one
or
three,
it's
yeah,
one
subtracted
from
the
other.
J
K
K
J
B
J
K
J
Quick,
I
I
think
this
is
we're
talking
about
having
a
nullable
designator.
This
would
stop
null
propagation.
I
think
this
no
longer
makes
sense
to
talk
about,
given
that
we've
decided
on
three,
because
the
question
mark
necessarily
marks
a
field
nullable
yeah.
So
I
think
I
think
the
question
mark.
K
I
think
your
last
question
is
more
helpful
or
you
know
the
other
piece
is
like
based
on
what
we
just
described
now:
there's
kind
of
two
kinds
of
errors:
there's
server
produced
errors
and
there
are
client
produced
errors
and
does
this
air
boundary
question
marky
thing
only
only
work
in
the
world
of
the
client
error
space
or
is
it
both
and
maybe
that's
a
more
interesting
question
asked
and
like
maybe
we
want
reading
material
for
people
to
think
about
that
first,
yeah.
J
I'm
gonna,
I'm
gonna
skip
this
discussion
just
because
I
think
I
think
the
previous
choice
makes
things
to
not
make
sense,
but
we
can.
We
can
come
back
to
this
at
a
later
date.
If
there's
still
questions
about
it,
all
right
error
handling
this
one
yeah,
it's
a
good
one.
Okay,
so
why
are
we
talking
about
error
handling
during
discussion
about
client,
controlled
nullability?
It
came
to
light
that
many
clients
deal
with
graphql
errors
by
throwing
out
entire
responses.
J
If
the
errors
array
and
a
graphql
response
contains
anything,
the
response
is
treated
as
if
it's
useless
some
of
the
options
we've
discussed
today
result
in
errors
being
appended
to
the
errors
array.
If
null
is
resolved
for
a
field
marked.
The
non-nullable
designator,
however,
part
of
the
intent
to
find
control
knowability
is
that
some
users
are
indicating
with
non-nullable
designators
that
they
can
handle
partial
results
or
opting
into
some
sort
of
error
state
throwing
out
entire
responses
on
account
of
client,
controlled.
J
Nullability
errors
isn't
ideal,
so
client,
controlled
nullability
becomes
a
pseudo-breaking
change
for
some
clients.
The
question
becomes,
what
would
clients
like
to
do
to
resolve
this
conflict
and
what
kind
of
information
will
they
need
to
do
it?
J
So
the
first
option
is
status
quo.
There
is
no
error,
handling,
there's
no
way
to
catch
errors.
Errors
produced
by
required
designators
act,
the
same
as
those
produced
by
sdl
non-nullable
fields,
yeah,
there's
that
errors
caused
by
client
control
nillability
are
treated
as
distinct
from
all
existing
errors.
J
There
are
some
sub
options
for
each
of
these,
so
we're
talking
about
excluding
errors
from
the
errors
array
or
include
errors
in
the
errors
array.
If
the
flag
is
enabled
on
execution
or
introducing
a
namespace
to
field
to
all
errors,
to
allow
clients
to
distinguish
between
them
or
introduce
a
boolean
flag
to
all,
errors
called
is
handled
or
something
like
that,
which
is
true.
If
an
error
is
handled,
all
client,
controlled,
nullability
errors
would
be
is
handled
as
true
introduce
a
separate
array
of
handled
errors
where
all
handled
errors
are
placed.
J
Instead
of
the
existing
errors
race,
all
client,
controlled,
nullability
errors
would
be
placed
somewhere
else.
Each
of
these
has
different
pros
and
cons,
but
this
is
an
example
with
the
namespace.
It's
an
example
with
the
is
handled
flag,
and
this
is
an
example
with
the
handled
errors
array.
J
And
then
the
last
option
is
to
introduce
some
query:
syntax
to
catch
errors.
Errors
are
caught
by
the
nearest
catching
syntax
and
in
the
event,
the
errors
are
not
caught
they're
treated
as
they
would
be
in
status
quo.
They
end
up
in
the
errors
array
in
past
discussions.
The
question
mark
which
has
in
the
past
mark
fields
as
nullable,
has
done
a
double
duty,
also
catching
errors.
For
the
sake
of
this,
I'm
trying
to
talk
about
them
as
if
they're
error,
handling
and
null
propagation
or
separate
things.
J
So
I'm
using
oh,
I
linked
the
wrong
one.
No
I'd
link
to
the
right
one
yeah,
so
I'm
using
this
sort
of
catch
directive
as
this
is
this
is
the
standard
syntax
until
we
decide
on
something
else.
So
in
this
case,
this
catch
would
do
one
of
the
previous
options
we
discussed
to
a
field
marked
with
client-controlled
nullability,
and
in
this
case
it
would
catch
all
errors
or
all
client
control,
nullability
errors
produced
by
fields,
child
fields,
and
this
would
catch
nothing.
J
So,
there's
there's
no
errors.
E
Does
does
the
catch
directive
make
it
nullable
as
well,
so
that
it
can
be
the
place
where
it's
caught.
J
So,
in
this
case
no,
I
was
trying
to
separate
the
two
discussions
and
I
want
to
talk
a
little
bit
about
why
I'm
doing
that.
Basically,
I
feel
that
returning
null
means
that
data
is
missing,
but
data
being
missing
is
not
necessarily
the
same
thing
as
there
being
an
error
and
there
being
an
error,
won't
necessarily
cause
data
to
be
missing.
So
I
feel
like
these
are
two
separate
things.
J
So
I
think
talking
about
these
two
sets
of
behaviors
separately
is
something
that
I
thought
was
important,
but
I'll
open
the
floor.
I
want
to
first
ask
again:
if
any
of
these
options
are,
are
our
blockers
for
you
or
your
use
case.
K
I
mean,
I
think,
based
on
our
previous
conversation,
this
first
one
probably
isn't
compelling
anymore
that
as
long
as
we're
in
the
domain,
where
an
exclamation
point
is
is
not
just
a
modification
of
a
type,
but
also
when
that
modified
type
is
invalidated.
Like
produces
a
special
kind
of
error
that
bubbles
in
a
different
way,
then
you
probably
need
some
way
to
handle
that
it
can't
always
just
float
up
to
the
top
and
blow
up
your
whole
query.
Q
J
O
Right,
I
don't
think
that's
too
big
of
an
issue
honestly,
because
even
even
in
this
world,
where
you
have
you
know,
client
control,
like
you,
have
the
exclamation
point
and
question
mark
any
client
that
uses
that,
if
there's
like,
if
we
stick
errors
in
the
error
or
what
ray,
when
you
know,
the
it
blows
up
and
is
caught,
that
seems
fine,
a
client
could
still
should
say.
Oh,
even
in
that
case,
I
want
to
blow
up
and
that's
fine,
like
that's.
That's
the
client
making
an
explicit
choice.
Q
Yeah
I
mean
the
handled
errors.
Thing
looks
like
we're
now
being
opinionated
about
something
that
clients
can
decide
on.
If
you
just
have
an
errors
away,
they
can
look
at
each
error
and
say:
oh,
this
error
is
a
ccn
error.
That's
fine,
I'll,
ignore
it
or
I'll.
You
know,
expose
it,
but
not
blow
everything
up
and
if
you
put
handled
errors
now
we're
making
the
server
opinionated
about
how
client
should
handle
that
it's
just
unnecessary.
J
B
That
is,
that
is
one
way
that
they
can
do
that,
and
the
past
tells
you
which
field
it
blew
up,
because
the
other
question
is,
if
like,
if
you
have
a
list
and
they're
there
you're
producing
errors,
and
it
could
be
a
lot
of
errors
that
overwhelm
you-
and
maybe
you
because
you're
producing
this-
you
say:
okay,
I
put
a
question
mark
on
a
nullable
field.
So
in
order
to
make
clear
that
I
I
only
accept
data
that
has
this
field
filled.
B
O
K
O
It
right
if,
if
producing
the
error,
produces
much
more
data
and
information
is
like
much
more
costly
for
the
server
to
do
and
you've
got
right,
you're
requesting
a
list
of
100
items
that
you
know
on
the
client.
You
know
that
those
hundred
items
are
all
null
and
you
use
the
non-nullable
syntax
to
force
the
server
to
spend
more
energy
like
producing
errors.
For
you.
A
A
I
don't
see
how
this
exclamation
point
makes
situation
worse
or
better.
E
Like
lee
said
earlier,
the
exclamation
with
sorry
the
errors
are
exceptional
like
they
aren't.
Your
schema
should
be
designed
in
such
a
way
that
when
you
say
something
is
non-nullable,
it
should
not
in
general,
throw
an
error.
So
this
is
where
a
user
knows
that
something
is
going
to
be
null
and
then
specifically
states.
This
should
not
be
null
and
causes
it
to
throw
an
error.
That
shouldn't
be
the
case.
If
we
didn't
have
client-controlled
nullability
in
the
majority
of
cases.
K
Q
Q
Oh,
this
is
a
ccn
error,
so
you
can
ignore
those
and
that's
not
a
huge
deal,
but
when
you
do
have
a
situation
where
you
have
hundreds
of
errors,
potentially
now
that
wouldn't
have
been
there
before,
you
have
to
iterate
through
every
single
one
of
them
and
check
if
their
ccna
or
should
determine
what
you
want
to
do
there,
and
that
might
be.
That
might
be
a
good.
K
Case
for
having
the
hand
thought
about
the
security,
the
security
vector
here-
that's
fair,
because
in
practice
it
is
the
case
that
a
lot
of
graphical
servers,
their
execution
path-
is
highly
optimized.
But
their
error
path
tends
to
be
on
the
slower
side
because
they
know
that
there's
a
reasonable
trade-off
there,
where
errors
should
be
rare
and
it's
okay
for
them
to
be
slow.
K
A
Interesting,
let
me
let
me
remind
you
guys,
I
put
there
a
big
description
of
the
station.
The
way
I
see
it-
and
I
think
a
lot
of
confusion
comes
here
from
the
word
error,
as
if
the
server
fails
at
something
when,
for
example,
you
put
exclamation
mark
at
some
field,
the
field
is
nullable
in
schema
and
on
the
server.
So-
and
you
say
I
know
it's
nullable,
but
with
this
id
of
the
object,
I
expect
it
to
be
non-nullable
and
you
send
it
to
the
server
server
executes
as
normal.
A
Up
to
the
last,
you
know
step
it
retrieves
the
data
and
it
is
about
to
send
it
back
and
then
it
says,
okay,
I
need
the
client
asked
me
to
also
check
this.
Okay,
let's
check.
Okay,
it's
now
the
assumption
of
the
client.
The
assertion
is
wrong:
it's
not
server
errors
and
talking
about
some
error
part
here,
it's
not
our
path.
It's
it's
just
the
question
of
executing
assertion,
client
assertion
at
the
end
and
adding
this
message
in
the
errors,
collection
or
somewhere
else
by
the
way.
A
K
I
like
this,
the
reframing
of
the
terminology
here
from
error
to
assertion,
because
that
that
is
a
better
description
of
what
we're
doing
here,
we're
making
a
client-side
assertion
about
the
types
that
we
want
to
be
able
to
operate
on
and
the
types
that
we
want
to
not
operate
on
and
the
query
behavior.
That
should
happen
as
a
result
of
that
the
the
root
problem,
just
to
kind
of
restate
it
please,
let
me
know
if
I'm
off
base
the
root
problem
is
existing
clients
make
assumptions
about
that
errors.
K
K
A
Let
me
let
me
bring
up
the
analogy,
so
let's
say
when
we
are
sending
something
to
the
server,
be
it
mutation
or
a
query.
A
We
send
some
data,
for
example,
to
search
or
to
update,
and
there
is
input,
data
validation
on
the
server
and,
let's
say
if
you
provided
some
invalid
string
somewhere,
we
return
it
as
an
error
right.
So
basically,
there
are
two
kinds
of
errors
that
we
can
return
in
errors,
collection
and
unfortunately
we
do
not
distinguish
it
explicitly.
So
there
are
client-side
errors.
A
Equivalent
of
bad
requests
in
http
sounds
like
everything
is
fine
on
the
server,
but
your
request
is
bad
and
the
other
one
kind
of
error
is
when
the
server
itself
failed
server,
error,
500..
A
So,
basically,
with
this
failed
assertion,
what
we
return
is
equivalent
of
the
bad
data
we're
telling
the
client
you
send
essentially
the
bad
bad
request.
You
assume
this
will
be
not
now.
No,
it's
not
so
I
don't
see
any
trouble
when
going
along
this
way.
I
don't
see
any
trouble
to
adding
this
response
to
the
errors
list,
because
it's
telling
the
client
you
have
a
bad
request
with
a
bad
assertion.
J
O
K
K
You
presented
here
are
like
describe
the
space
necessarily
you
know
like.
I
don't
know
that
a
vote
here
is
going
to
be
super
helpful
for
you
yeah,
just
because
this
is
intermixing,
syntax
decision
errors,
array
behavior.
I
I
think
you
can
probably
take
a
crack
at
exploring
it
a
little
bit
and
then
come
back
with
a
little
bit
more
of
a
clear
branching
factor.
Yeah.
J
Q
Okay,
I
would
like
to
just
note
really
quickly
that
I
I
think
that
the
biggest
issue
here
is
having
a
massive
amount
of
these
errors
would
be
very
likely
and
that
could
easily
be
solved
by
either
doing
something
with
file
assertions
but
aggregating
these
errors.
So
you
don't
have
an
entire
massive
error
object
for
every
single
one
of
these
hundreds
of
areas.
You
just
have
one
client
detroit
controllability
error
that
has
a
list
of
here
are
all
of
the
fields
or
the
paths
that
did
have
an
assertion.
Failure.
B
A
Then
yeah,
then
guys,
please
pay
attention
to
the
discussion
there
initially,
because
I
raised
all
these
arguments
there
and
it
sounded
to
me,
like
nobody,
read
them
essentially,
for
example,
suggesting
to
treat
it
as
assertions
and
regarding
the
errors
so
that
we
we
don't
have
we
don't
run
out
of
time
here.
J
Great,
if
people
want
to
put
the
option
they
they'd
like
to
select
in
the
thing
it's
non-binding,
I'm
not
going
to
do
anything
with
it,
but
it's
good
to
know
and
then
yeah.
We
can
move
on
to
the
next
thing
and
I'll
record.
It.
K
Second,
roman
suggestion
there
we'll
take
discussion
back
to
the
the
discussion
threads
you
set
up
alex
thanks
for
the
structured
conversation
that
was
super
helpful,
yep
yeah,
no
problem,
it's
helpful
for
me
too.
K
O
Yeah
yeah,
I'm
I'm
presenting
this,
but
at
ricky's
request
basically
like
the
ricky,
is
looking
to
basically
not
spend
so
much
time
on
the
lead
portions
of
graphical.
O
So
what
that
means
is
like
being
the
sole
person
that
all
pr's
have
to
go
through
or
being
the
sole
person
that
any
organization
has
to
go
through
so
she's
looking
to
ramp
up
a
couple
of
other
maintainers,
I
know
yuri,
is
on
the
call
and
is,
I
believe,
one
of
the
the
people
she
ricky's
currently
ramping
up
but
yeah.
Basically,
this
is
just
a
call
to
graphical.
Has
a
lot
of
momentum?
O
Has
a
lot
of
new
has
like
gotten
design
people
to
come
in
with
design
background
to
redesign
how
it
should
look
and
there's
a
lot
of
there's
an
existing
roadmap
with
a
lot
of
work
in
this
space?
It's
very
exciting
and
we
don't
want
to
like.
K
I
do
want
to
mention
that
tim
suchenek
reached
out
to
me
and
expressed
interest
in
helping
here
and
asked
for
a
little
bit
of
my
time
to
help
explain
to
him
what
he
needed.
I
invited
him
to
this
meeting.
I
think,
unfortunately,
he
wasn't
able
to
make
the
time,
but
hopefully
he
can
in
the
future,
but
that's
at
least
one
person
that
has
done
good
stuff
in
the
community
before
may
be
helpful.
O
I
think
that
he
is
the
other
person
that
ricky
has
begun
to
ramp
up
or
like
has
talked
to
I'm
not
100
certain,
but
even
even
if
there
are
a
couple
people,
the
more
people
who
are
interested
and
who
are
like
active,
probably
the
better
for
now,
especially
as
there's
an
opportunity
to
get
a
lot
of
ramp
up
in
a
lot
of
context
dumps,
it's
probably
better
to
like.
K
Agreed,
if
anyone
here
is
interested
in
contributing
to
that
or
if
you've
got
a
co-worker
who's
looking
for
some
cool
open
source
stuff
to
work
in
yeah,
send
them
our
way.
My
hope
is
that,
between
yuri
and
tim,
that
will
have
some
good
leadership
in
place
and
we'll
be
able
to
activate
a
bunch
of
folks
who
just
want
to
be
able
to.
You
know,
chip
away
at
stuff.
L
Yeah,
so
at
the
guild
we
are
helping
out
with
graphical
v1
maintenance
and
we
would
love
to
like
take
more
roles
and
help
out
with
the
v2
and
whatever
it
needs
to
be
done
so
yeah.
Let
us
know
if
there's
anything,
we
can
open.
K
Fantastic
well,
hopefully,
we
can
make
some
progress
relatively
soon
like
I
was
mentioning.
I'm
gonna
sit
down
with
tim
sometime
next
week
and
just
hear
from
him
what
he's
able
to
do
personally
and
then
maybe
sometime
between
now
and
our
next
call.
We
can
reboot
the
graphical
working
group
subcommittee
thing
and
school
people
up
and
get
us
discussion.
K
Thanks
for
making
sure
that
didn't
fall
through
the
cracks,
not
all
right
rob
will
let
you
have
the
remainder
of
the
time
stream
and
defer.
S
Hey
so
I
wanted
to
go
over
a
little
bit
more
about
what
we
talked
last
month.
This
was
how
to
handle
non-nullable
errors
that
bubble
up
in
stream
and
deferred
payloads.
S
Just
background
of
the
issue
is
with
non-nullable
behavior.
The
error
should
bubble
up
to
the
first
nullable
field
that
may
be
in
a
previous
payload
or
in
the
initial
payload,
and
can't
go
back
in
time
and
undo
that.
S
So
I
think
that
there
was
like
general
consensus
that
putting
deferring
stream
acts
as
a
null
boundary
kind
of
because
it
has
to.
There
was
a
question
of
how
to
distinguish
between
a
null
result
and
a
null
result
that
should
have
continued
to
bubble
up.
S
That
is
not
really
an
issue
for
deferred
payloads,
because
deferred
is
only
allowed
on
fragments.
That
means
that
every
deferred
payload
should
be
an
object
in
the
data
field,
and
if
it
bubbles
up
all
the
way,
we
can
return
a
null
there
instead,
and
you
will
then
know
that.
S
That's
what
happened
for
stream.
The
proposal
has
been
that
the
data
field
and
stream
is
the
list
item.
If
that
bubbles
up
bubbles
up
all
the
way
to
null.
S
It's
potentially
ambiguous:
if
was
that
a
null
data
result,
or
should
it
have
continued
bubbling
up
to
the
list,
so
there
was
a
suggestion
that
stream
payload
data
could
be
wrapped
into
an
array
that
would
have
another
point
where
that
could
be
nulled
out.
That
was
also
brought
up.
That
could
be
potentially
useful
for
handling
batches
of
results.
S
So
I
wanted
to
go
through.
I
got
some
feedback
from
joe
savona
of
the
relay
team
that
I
wanted
to
go
over.
I
was
hoping
he'd
be
able
to
make
it,
but
I
don't
think
he
can
so
I'm
going
to
share
my
screen.
S
S
So
joe
is
asking
that
we
consider
the
fragment
the
name
fragment
response
proposal,
that's
also
ongoing,
which
would
allow
someone
to
distinguish
if
it
was
needed
and
that
I
think
that
it
did
kind
of
seem
like
it
was
an
edge
case
for
clients
that
would
want
to
make
that
distinction,
and
he
had
an
example
of
what
that
would
look
like
here,
and
I
think
another
interesting
thing
that
he
brought
up
was
that
the
way
that
facebook
handles
batching
is
by
instead
returning
arrays
of
these
payloads,
instead
of
specifically
having
an
array
of
stream
an
array
of
the
stream
data,
and
the
benefit
of
that
is
that
it
allows
you
to
batch
together,
payloads
from
both
defer
and
different
streams
instead
of
just
data
from
a
single
stream.
M
Hey
so
I
just
I
just
wanted,
I
mean
to
explore
that
a
little
further
in
terms
of
the
different
types
of
batching,
I
managed
to
put
together
an
implementation
that
can
do
can
do
both
and
I
think
there's
definitely
definitely
a
a
benefit
to
doing
both
from
what
I
understand
in
his
comments.
He's
able
to
you
know,
say
basically
that
we
send
all
the
payloads
that
are
ready
at
the
same
time,
but
a
client
might
want
to
say
I
only
want
you
know.
M
Batches
of
stream,
payloads
10
at
a
time
really
need
them
10
at
a
time
or
100
at
a
time,
and
in
that
case
we
can,
you
know
we
can
reduce.
You
know
we
can
reduce
the
number
of
payloads
that
are
sent.
So
it's
not
just
you
know.
So
it's
two
different
types
of
you
know
all
together.
So
it's
like
two
different
types
of
batching
that
both
are
going
to
be
useful.
M
I
also
put
in
the
in
the
chat
I
put
in
a
link
to
what
currently
I'm
doing
in
terms
of
the
different
syntaxes.
That's
the
right
grammar
for
batched
and
parallel
streams.
M
B
B
Are
you
then
saying
I
want?
I
want
to
match
at
least
this
amount
of
items
or
it's
client.
M
Yeah,
so
I'm
not
sure
exactly
how
they
implemented
it
at
facebook
I
mean
what
I
took
from
his
suggestion
is
that
you
mean
the
client
overall
would
have
to
dictate.
You
know
how
many
payloads
they
want
at
a
time
and
the
server
would
take
a
look
at
how
many
are
ready
and
send
them
at
a
time,
but
it
wouldn't
be
it
would.
M
I
don't
think
it
would
be
easily
definable
on
a
per
operation
basis,
but
when
you're
using
the
stream
directive,
you
know
to
batch
and
say:
listen
hold
off,
don't
send
me,
you
know
any
items
until
you
reached
a
certain
size,
then
you
can
sort
of
indicate,
I
guess,
on
an
operation
basis.
You
know
how
many
you
know
how
you
know
how
how
large
the
batch
is.
That
gives
you
also
additional
flexibility
there.
I
think.
K
There's
two
related,
but
subtly
different
things
happening
there.
One
is
a
client
expressing
intent
and
rob
check
me
if
I'm
wrong,
but
I
believe
that
stream
already
has
this
functionality
in
place.
Right
where
you
can
say
you
want
to
describe
the
the
number
for
the
first
payload,
the
number
of
items
to
be
in
that
first
payload
yeah,
that's
part
of
it.
K
I
think
facebook's
metas,
I
don't
know
if
they
still
have
this,
but
at
some
point
I
knew
they
had
flexibility
in
like
describing
the
size
of
each
subsequent
payload
as
well,
but
that
was
like
purely
through
the
lens
of
what
should
the
end
user
experience
be
like?
Do
you
want
to
see
them
come
in
in
big
chunks?
Or
do
you
want
to
see
them
come
in
one
at
a
time
you
know
it's
like
customer
perceivable,
so
you
want
client
control
the
other
related,
but
subtly
different
is
the.
K
So
the
client
wants
to
be
able
to
specify
some
intent
about
constraints
around
batching,
either
in
the
initial
batch
or
subsequent
batches.
I
think
the
initial
one
is
what's
most
important
and
then
the
server
wants
to
be
able
to
pay
load.
Those
in-
and
you
know
whatever
chunk
sizes
is-
is
most
efficient
for
it
to
do
so.
S
I'm
I'm
not
like
completely
satisfied
what
I
have
built
just
yet,
but
but
I
was
thinking
something
like
if,
if
we
support
returning
async
intervals
from
resolvers
and
those
could
return
batches
of
items
and
all
of
the
fields
underneath
it
are
synchronous,
then,
when
the
client
asked
the
graphql
server
for
the
next
result
from
its
async
interval,
you
would
have
a
bunch
of
payloads
that
are
ready
and
they
would
all
be
sent
in
an
array
and
so
like,
and
so
there
doesn't
really.
There
doesn't
need
to
be
any
like
delays
introduced
for
that.
S
No,
I
I
don't
have
it.
Okay,.
B
Just
out
of
curiosity,
because
because
if
you,
if,
if
you
are
highly
paralyzed
executing
stuff,
it
could
could
be
efficient
to
to
have
a
delay
there
right,
but
but
I
mean
that's-
that's
implementation,
specific
of
the
server.
The
question
was
more
for
me.
If,
if
you
do
such
as
such
a
thing.
B
S
Were
you
saying
something
lee
you
were
you're
admitted,
okay,
yeah.
I
I
mean
I
was
thinking
that,
like
there's
in
the
reference
implementation,
we
probably
shouldn't
have
like
any
kind
of
delays,
but
it'd
be
easy
enough
to
add
some
kind
of
wrapper
around
that
async
interval
that
where
you,
if
you
didn't
want
to
like
wait,
I
don't
know
some
amount
of
time
before
for
anything
else
like
that
could
be
something
in
the
network
layer
if
it
was
needed,
but
I
mean
I
guess
I
guess
I'm
like.
S
M
I
mean
I,
I
think,
we're
considering
this
again,
because
you
know
the
two
topics
of
batching
and
and
what
to
do
about
to
distinguish
between
like
a
null
that
bubbled
up.
You
know
when
you
have
when
you
have
a
list
of
non-nullable
items,
and
one
of
them
is
no.
So
what
we
decided
last
meeting
was
to
you
know
that
case
should
be.
M
The
data
property
should
be
set
as
null
and
otherwise
it'll
be
an
array
of
items,
and
so
that
question
of
how
to
deal
with
that
issue-
and
you
know
whether
we're
gonna
you
know-
support
batching.
Those
are
kind
of
interrelated,
because
that
was
you
know
how
we,
how
we
decided
to
support
that
issue.
M
Saying
that
maybe
we
could
adopt
what
what
joe
was
saying
was:
is
sort
of
no
longer
really
use
the
array
and
maybe
use
batching
in
a
different
way,
and
so
that's
how
the
topics
are
related.
B
But
the
the
one
batching
is
batching
on
stream
like
having
an
array
as
a
stream,
payload
or,
and
the
other
thing
would
be
even
batching,
together
stream
payloads,
together
with
defer,
payloads,
possibly
and
sending
essentially
these
down
the
stream
that
are
different,
processed
items,
that
you
would
then
merge
and
send,
and
one
go
down.
As
I
understood
it,.
M
Agreed
agree
there
there
are
slightly
different
types
of
batching,
I
mean,
maybe
I'm
not
thinking
through
them
entirely.
I
think
they're
both
useful.
I
don't
know
what
joe
would
respond
to
that.
B
Because,
because
the
latter,
one
where
you
batch
two
payloads
together,
you
have
to
also
send
down
two
passes.
Essentially,
you
you
have
to
give
two
patch
informations
down,
because
they're
these
payloads
could
go
into
totally
different
places
in
the
graph
and
the
result
graph.
B
So
so
it's
it
sounds
like
the
batching
that
we
also
have
are
doing
with
other
things
of
a
overhep
where
you
send
into
to
request.
Get
two
results
back
in
one
go
so
yeah.
Could
this
be
implemented
later?
Do
we
need
to
so
do
that?
No.
O
That
that
batching
is
not
required
to
do
right
now,
joe
joe's
saying,
if
we're,
if
you're
going
to
do
batching,
why
not
do
it
with
the
multiple,
basically
multiple
responses
in
the
same
batch
and
that's
fine,
the
I
I
think
the
reason
we're
having
this
discussion
at
all
is
not
that
we
necessarily
want
to
implement
multiple
batching
immediately
but
ins,
even
though
it
sounds
like
I
think,
yakov
has
managed
to
do
that,
but
rather
that
we
want
to
know.
O
B
S
Right
that
I
think
matt
summarized
why
why
we're
talking
about
this
and-
and
I
I
think
for
me-
the
question
is
we
had
said
previously
that
like,
if
we
add
this
array
wrapper
around
this
object,
that's
a
convenient
thing
to
do
to
handle
bubbling,
and
it
also
might
be
useful
for
batching
later,
but
I
wanted
to
first,
I
guess
address
the
point
of
if
we're
thinking.
S
If
I
mean
facebook
had
clearly
thought
that
handling
batching,
this
other
way
was
more
was
better,
and
so
I
wouldn't
want
to
make
the
wrong
decision
there.
Thinking
that
we
could
do
something
later,
when
that's
not
actually
the
right
path
to
go
down.
O
Yeah,
I
I'm
less
worried
about
that,
like
it's,
it's
very
easy
to
implement
the
other.
The
joe's
form
of
batching
like
it
doesn't
require
any
syntax
changes.
It
doesn't
require
any
like
real
logical
adjustments.
Besides,
the
server
needs
to
know
that
it
can
send
multiple
payloads
all
at
once
and
like
clients
might
need
to
be
able
to
handle
in
the
same
response.
Getting
two
different
json
objects
like
side
by
side
that
are
not
part
of
some
like
list
which
that's
fine,
but
the
right.
O
E
If
you
have
to
specify
the
path
and
index
of
each
of
those
strings,
that's
a
quite
significant
in
increase
in
the
size
of
the
the
payloads.
To
do
that,
so
I
think
we
should
wrap
it
with
a
list
at
that
inner
data
level,
which
then
means
if
there
is
a
null
there,
it
means
the
same
thing
as
it
does
for
defer.
So
I
think
it
solves
those
two
problems
with
one
stone,
whether
or
not
we
also
wrap
the
payload
itself
in
a
list
as
well.
O
We
basically
missed
this
substantial
edge
case,
and
I
don't,
I
think,
it's
reasonable
for
open
source
to
say,
hey.
We
actually
do
have
to
handle
this
edge
case,
and
this
is
a
reasonable
thing
for
us
to
like
back
port
and
fix.
M
Yeah,
I
mean
just
just
to
argue
joe's
side.
I
guess
because
he's
not
here
I'll
do
my
best
to
understand
it.
I
think
what
he,
what
he's
saying
is
there's
some
some
like
redundancy,
because
if,
if
the
field
is
nullable,
then
then
it
can
never
happen
that
the
whole
array
will
be
no
right.
You
know,
because
you
know
the
whole
array
could
be
initially
no,
but
in
a
subsequent
payload
you
know
that
you
know
we've
already
pat,
you
know
the
the
cow
is
out
of
the
barn.
M
Is
that
an
expression
so
to
the
so
you
know
it
can
no
longer
be.
No.
You
know
it's
a
subsequent
payload.
The
whole
list
can't
be
now
and
if
the,
if
the
list
items
are,
if
the
list
items
are,
are,
let's
see
what
case
did
we
do?
We
did
if,
if
they're
not
null
of
all
right,
we
did
that.
So
if
they
are
nullable,
then
we're
never
going
to
have.
M
You
know
the
whole
list
be
no,
so
both
both
cases
are
sort
of
mutually
distinct,
and
if
you
have
knowledge
of
the
schema
I
mean,
if
the
client
has
knowledge
of
the
schema,
they
can
be
able
to
tell
the
difference
between
the
two.
So
that's
what
he
was
saying
if
we
don't
have
batching
now
I
happen
to
be
in
the
bathroom
here,
so
you
know,
but
I
I
do
see
his
point
there,
but
my
only
my
only
concern
would
be
you
know
it
just
looks.
M
S
Okay,
so
I
I
definitely
would
like
to
avoid
supporting
batching
up
front
and
hoping
that
it
could
be
something
that's
added
later,
so
I
do.
We
think
that
it's
a
viable
path
to
go
forward
that
we
do
just
ship
with
in
a
stream
payload.
The
data
is
always
wrapped
in
array.
There's
always
one
element
to
it,
and
if
that
element
was
non-nullable
type
and
a
return
null
and
it
bubbled
up,
we
could
return
null
for
that
entire
data
as
a
result
for
data.
O
Yeah,
I
don't,
I
don't
think
I
don't.
I
don't
know
how
much
joe
cares,
but
if
this
is
like,
if
this
is
the
best
thing
for
open
source-
and
I
think
we
have
bad
down
that
it
is,
then
I
I
don't
see
a
real
problem
with
this.
B
I
mean
batching
can
still
be
done
or
we
can
still
look
later
at
batch,
how
we
do
how
we
solve
the
batching
case,
but
I
also
think
if
we,
if
we
get
the
basics
in
first,
we
don't
get
lost
in
solving
those
two
problems
together.
S
Right
and
I
guess
what
I
was
concerned
about
with
the
with
like
batching
the
whole
payloads
is:
if
we
don't
do
that
originally,
then
the
api
for
graphql
is
always
an
async
iterable
of
payloads,
but
if
we
want
to
change
it
to
an
async
interval
of
either
payloads
or
array
of
payloads
should
should
we
like
do
that,
just
say
that
it
could
that
that
could
be
the
case
upfront
and
then
put
off
a
potentially
breaking
change
later,
or
is
it
worth
the.
O
I
see
it
because
the
other
thing
is
we
write.
I
I
think
it
was
brought
up
this.
This
does
change
like
all
right,
the
async
hitter
a
little
bit.
Does
it
make
more
sense
to
just
leave
it
yeah?
This
is
hard.
I
don't.
I
don't
know
sorry.
O
It's
it's
also
data.
Might
when
it's
when
it's
this
list,
data
might
not
be
the
right
word
either.
It
might
be
the
case
that
it
should
actually
be
something
like
items
if
it's
a
list
at
which
point
it's
like
well,
if
it's
items
then
that
we
could
already
like
future
support,
that
we
could
keep
data
being
the
singleton
item
and.
B
E
So
one
of
the
things
that
I
was
thinking
about
just
now,
which
I've
not
actually
thought
about
before
was
typically
with
graphql.
If
you
have
a
client
that
doesn't
necessarily
know
what
the
query
is
right,
just
issues
a
query
to
the
server,
it
gets
the
response
back
and
then
it
knows
what
to
do
with
it,
because
the
response
has
enough
data
in
it
to
tell
it
what
to
do,
but
that's
already
the
case
for
graphql
currently.
E
So
the
the
at
index
that
that
rob's
put
in
here
now
is
fine
and
indicates:
oh,
it's
got
an
at
index,
so
it
it's
got
to
be
an
append,
but
it's
also
kind
of
redundant
because
you've
already
received
we've
we've
guaranteed
that
they're
in
order,
so
we
already
know
what
index
will
be
next.
If
you
go
with
what
you've
just
proposed
and
use
the
data
and
items,
then
it's
clear
that
an
items
gets
appended
a
data
gets
merged.
B
O
So
I
I
think,
maybe
maybe
we're
getting
hung
up
on
data.
What
if,
if
the?
If
the
key
was
item,
singular
just
item
yeah,
then
we
would
know
okay.
This
is
one
thing
and
if
item
is
null
that's
fine,
then
we
can
say.
Oh
if
item
isn't
there
is
unset,
then
it's
an
error
and
it's
not
it's
not
symmetric
in
the
same
way
that
it
is
with
defer.
O
But
if
the
actual
like
key
is
its
own
independent
thing,
then
maybe
that's
like
it's.
It's
kind
of
we're
like
working
ourselves
in
circles
because
we
want
the
symmetry
between
them
and
I
think
lee
was
a
huge
proponent
of
having
that
symmetry
between
defer
and
stream
and
what
data
being
null
means
and
data
being
unset
means,
but
maybe
stream
is
different
enough
that
it
deserves
its
own
naming.
I
don't
know.
M
O
B
Yeah,
it
could
solve
a
lot
of
issues
that
we
have
for
the
client
really
understanding
what
has
to
be
done
right.
A
We
we
are
trying
over
specify
my
main
question:
does
it
all
these
details
and
strict
restrictions
doesn't
do
they
have
to
be
in
the
spec
in
the
standard,
because
I
can
think
about
so
different
situations
when
all
this
can
be
used?
Remember
that
it's
not
like
our
spec
is
directly
executed.
There
is
a
server
framework.
Then
there
is
the
server
which
is
used,
for
example,
for
things
like
one
thing
is
facebook,
when
I
scroll
down
my
stream,
probably
there
would
be
some
stream.
A
I
see
that
things
appear
out
of
order
because
I'm
down
in
my
stream,
but
the
freshest
news
appear
right
there
out
of
order
technically,
but
they
go
out
of
order.
If
I
close
facebook
open,
they
will
appear
on
top
right
or,
for
example,
the
stream
of
stock
quotes.
They
are
completely
different
and
probably
the
server
when
they
implement
particular
endpoint
or
the
field
or
whatever
they
will
have
to
specify
essentially
how
it
works
and
for
them,
for
example,
if
we
missed
something
how
we
will
probably
deliver
it
later
right
away.
A
If
some
our
of
our
partners
have
had
a
glitch
for
a
few
seconds,
we
will
miss
their
data.
We
will
deliver
them
first
and
the
clients
will
have
to
you
know
build
around
this,
but
it
will
be
server
specification
for
particular
case
how
they
will
handle
all
these
details.
I
think
we
should
here.
We
should
provide
generic
framework
and
say
that
some
servers
can
do
this,
follow
strict.
You
know
water
some
can
put
now
somewhere
and
deliver
it
later
and
so
on,
because
there
are
so
many
different
situations
out
there.
O
A
O
Think,
given
there
are
so
many
situations,
it's
really
really
important
that
we're
very
specific
on
what
the
spec
change
actually
is.
I
think
that
that
is
actually
why
it's
so
valuable.
B
H
S
Let's,
let's,
let's
see
if
we
can
just
spend
a
few
minutes
on
this
yeah,
so
this
came
up
about
validating
the
label
fields.
The
idea
is
that
clients
provide
a
label
to
defer
and
stream.
S
It
should
be
unique
and
then
the
label
is
spit
back
out
on
the
payloads
that
match
up
with
the
directives
and
that's
how
the
clients
can
match
up
where
the
what
payload
belongs
to
came
from,
which
directive
we
did
say
a
while
back,
that
label
could
be
optional
if
you're,
just
a
client
that
doesn't
care,
you
don't
send
it,
you
don't
get
it
back
the
spec
that
as
of
right
now,
says
that
if
you
do
send
it
you
get
back
whatever
you
put
in.
I
think
I
had
made
some.
S
I
think
I
mentioned
that
they
should
be
unique
in
the
spec,
but
I
there's
no
validation
for
that.
S
O
F
O
I
can
think
of
one
if
I'm
sending
the
same
query
multiple
times
with
slightly
different
arguments.
It
is
there.
There
is
a
world
in
which
a
client
would
use
the
labels
from
different
query
like
the
label
would
be
an
incremented
count
that
gets
passed
in
as
an
art
as
a
variable,
so
that
I
could
differentiate
between
two
different
queries
of
the
same
name
with
the
like
that
have
different
values
that
I
want
to
be
merging.
K
So
yeah,
I
feel
like
it
opens
a
can
of
worms
like
if
you
have
to
have
run
time,
checking
that
yeah,
like
you,
have
to
globally
look
at
everything
in
the
query
to
see
if
multiple
of
these
exist
and
that
their
labels
aren't
going
to
conflict.
Also,
like
I'm
still
not
sure,
I
totally
understand
the
value
of
the
label
argument
like.
Is
it
just
to
uniquely
represent
these?
Can
we
do
that
with
the
path
into
the
query
like
it
seems.
O
Like
you
can't
do
it
with
path,
because
you
could
have
the
same
field
with
two
different
defer
or
like
you
could
end
up
with
the
same
field
being
deferred
in
two
different
places.
But
I
mean
in
the
two.
K
Not
in
the
not
in
the
response
path,
but
in
the
in
the
query
like
follow.
If
you
were
to
crawl
the
ast.
Each
of
these
have
a
unique
location
in
the
ast
of
the
query
itself.
Right.
K
O
Path,
though,
do
we,
we
use
the
response
path.
Yeah.
B
Yeah
yeah,
it's
more
like
a
fragment
identifier
could
help
like.
If
you
know,
okay,
this,
this
deferred
fragment
is
fulfilled.
So
you
can
emulate
that.
I
think
melt
showed
that
with
the
it's
fulfilled
and
then
you
ideas,
the
type
name
like.
K
O
Yeah,
it's
I
as
michael
was
saying
it's
because
it's
basically
because
we
don't
have
fragment
keyed
fragments,
so
we
use
it
to
say
which,
like
which
fragment
it
got
a
fulfillment
or
not.
B
We
actually
went
away
from
from
the
label
in
the
neckline
that
we
are
doing
because,
and
so
we
we
are
actually
using
the
workaround
that
you
stated
so
we
have
an
aliased
type
name
here,
because
there
you
have
an
if
on
the
defer-
and
sometimes
it's
not
deferred-
and
we
still
have
to
recognize
is-
is
the
is
the
fragment
immediately
fulfilled,
or
maybe
the
server
says?
Okay,
I
have
the
data
immediately.
I
send
that
down
the
first
ish
payload,
so
the
label
is
not
that
valuable.
K
Yes,
I
agree
to
dig
back
to
rob's.
I
think
rob
has
had
a
couple
micro
sub
questions
here.
Like
should,
should
label
be
required?
I
you
know
clearly
we're
deriving
some
value
from
having
label.
I
think
that's
fine,
but
my
read
on
it
is.
It
sounds
like
a
hack
because
we
don't
have
some
other
feature
in
there,
rather
than
like
a
core
to
the
behavior
of
different
stream
working,
and
maybe
that's
why
I
didn't
understand
how.
K
And
if
and
if
that's
the
case,
then
it
seems
crazy
to
me
to
require
them
to
say,
like
hey,
there
are
clients
out
there
that
need
this
hack.
Therefore,
everyone
must
add
this
thing,
even
though
they
don't
understand
what
it's
for.
That,
I
think,
would
be
tough
for
us
to
stand
by
that
decision,
but
for
the
ones
where
we
have
them
in
there.
K
K
And
if
I
can
back
up
and
generalize
it,
let
me
know
if
this
is
the
wrong
characterization
like
if
we
were
to
describe
this
in
a
way
that
wasn't
like
this
is
a
hack,
because
some
clients
use
it
for
this
weird
purpose.
The
generalized
way
to
frame
it
would
be
if
you
want
to
look
at
the
payloads
coming
in
your
streamed
response
and
link
them
to
specific
nodes
in
your
ast,
for
where
defers
and
streams
occurred,
labels.
The
way
in
which
you
tie
those
two
together
is
that
right,
yeah.
This
is.
O
For
for
very
legacy,
graphql
given
graphql
is
now
10
years
old.
This
is
the
equivalent
of
like
client
mutation
id.
K
No
there's
there's
definitely
inherent
value
there
and
I
can
imagine
future
clients
also
leveraging
this
in
different
ways
to
be
able
to
say
I
don't
know.
Maybe
they
have
some
client
local
additional
directive
that
describes
like
loading
indicator,
behavior
or
something
specific
like
that,
and
you
want
to
know
when
a
particular
deferred
stream
has
completed.
B
But
because
the
the
because
we
can
omit
that
you
know,
I
think
you
you
cannot
really
do
that,
because
the
server
can
decide
not
to
send
the
deferred
payload
and
then
send
it
in
the
initial
initial
result.
So
when
you
wait
for
the
label,
you
will
never
get
them.
B
S
E
E
Sorry
yeah,
what
I
was
saying
is,
I
think,
what
what
michael's
saying
is,
because
you
can
choose
not
to
adhere
to
stream
at
all,
like
you
can
receive
the
stream
directive
and
not
stream.
You
just
return
the
data
as
part
of
the
original
payload.
The
key
might
never
arrive
the
label.
B
Yeah,
what
the
difficulty
here
is
is
so
the
server
can
say:
okay,
you
deferred
actually
fields
that
we
already
have
when
when
you're
you're,
you
come
to
that
point.
So
I'm
sending
the
these
fields
in
the
initial
payload,
but
there
still
might
be
other
defers
that
come
so
you
will
get.
Maybe
a
has
next,
but
the
label
that
you're
waiting
for
will
never
come
because
it's
fulfilled
in
the
first
request.
There
are
some
labels
that
come,
but
the
label.
K
Is
not
yeah,
that's
what
I
mean
like.
Should
we,
in
addition
to
having
this
house
next
field,
have
an
additional
thing?
That's
like
deferred
labels
or
something
like
that.
It's
an
array
of
like
if
it
exists
in
that
array,
then
that
means
that
one
of
the
subsequent
payloads
is
also
going
to
have
that
label
and
kind
of
close
it
out
of
your
list
just
to
give
you
both
of
the
bookends
of
like
yup.
You
are
waiting
on
that
and
okay.
Now,
you
are
no
longer
waiting
on
that.
D
D
K
Don't
want
to
like
invent
new
behavior
if
it's
unnecessary,
especially
if
kind
of
the
purpose
of
this
is
for
a
specific
use
case.
But
michael
you
bring
up
a
good
point
and
if
that
is
exposing
some
surface
of
bad
behavior
and
the
clients
that
we
are,
that
are
already
leveraging
some
version
of
this.
I
don't
know.
Maybe
we've
maybe
we've
misunderstood
something.
B
O
It
would
be,
it
would
be,
that's
we've
sort
of
like
it
would
be
the
better
solution,
it's
just
not
what
we've
actually
done
and
it
would
be
exactly
to
actually
do
it.
F
S
K
S
Okay,
well,
I
I
think
I
can
move
forward
with
having
the
validation
role
to
enforce
that.
If
label
is
provided,
it's
static
and
it's
a
and
it
is
unique,
and
then
I
think
I'll
assume
that
that's
okay
moving
forward-
and
we
could-
I
mean,
having
more
fields
on
about
saying
that,
like
this,
like
you
were
saying,
if
these
are
fragments
were
already
fulfilled
or
something
that's
something
that
could
be
added
in
a
non-breaking
way
later.
So.