Skip to content

Commit e82b776

Browse files
benjiebenjie
authored
Add notes from January WG (#1632)
1 parent e18fe8c commit e82b776

File tree

1 file changed

+150
-0
lines changed

1 file changed

+150
-0
lines changed

‎notes/2025/2025-01.md

Lines changed: 150 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,150 @@
1+
# GraphQL WG Notes - January 2025
2+
3+
**Watch the replays:**
4+
[GraphQL Working Group Meetings on YouTube](https://www.youtube.com/playlist?list=PLP1igyLx8foH30_sDnEZnxV_8pYW3SDtb)
5+
6+
Agenda:
7+
[https://github.com/graphql/graphql-wg/blob/main/agendas/2025/01-Jan/09-wg-primary.md](https://github.com/graphql/graphql-wg/blob/main/agendas/2025/01-Jan/09-wg-primary.md)
8+
9+
## TSC Election update
10+
11+
- Issue:
12+
[https://github.com/graphql/graphql-wg/issues/1612](https://github.com/graphql/graphql-wg/issues/1612)
13+
- We’ll be closing the application process 10th of January 2025
14+
15+
## TSC GitHub permissions
16+
17+
- Some TSC members have ownership permissions
18+
- Rather than every TSC member having ownership permissions
19+
- Let’s save it for a different time as Lee is not here
20+
21+
## GraphQLConf 2025
22+
23+
- Amsterdam September 8 - 10 2025
24+
- We want more community - WG involvement
25+
- We want you to attend, tell us why and how we can help you
26+
- There might be a working group track during what’s normally the unconference
27+
day
28+
- Working group leaders for composite schemas, … would do a talk and have
29+
discussions
30+
- Being in the same room can spark new ideas
31+
- Michael, good idea, having dedicated discussion time would be a great change
32+
- Martin, how would this work? Would it be interested people or the general
33+
audience?
34+
- Martin, workshops might be better to spark discussion
35+
- Michael, I thought more about user group style, champions talk about the
36+
topics and the current state. Then after you have time to mingle and talk to
37+
the people.
38+
- Michael, the main difference with the regular talk format is that it isn’t
39+
packed, we have dedicated discussion time.
40+
- Benjie, my idea is the champions have talks, there will be some tables and
41+
people can approach the tables that interest them (based on
42+
topics/subtopics). Discussions of 8-10 people, then people from each table
43+
can surface the ideas from their table to the general group.
44+
- Benjie, the audience is wider than the working groups, it will be a narrower
45+
group than the conference audience but interested people that touch on these
46+
topics, like folks writing GraphQL clients.
47+
- Jeff, there was also talk about doing working sessions
48+
- Benjie, introducing a slightly wider audience is the goal, this could give
49+
us an opportunity for a lot more feedback
50+
- Michael, aren’t these people involved in the working groups already? For
51+
example in Microsoft conferences product managers invite you to give
52+
feedback on their spare time.
53+
- Benjie, if people have more thoughts or ideas or know what works and what
54+
does not please reach out
55+
- Benjie: is there anyone we should include for various topics, like subject
56+
matter experts that work on GraphQL clients. Anyone eager to MC, …?
57+
- Martin, what is the best way to reach out?
58+
- Benjie, Discord in the graphqlconf channel
59+
60+
## Changing error handling of subscription streams
61+
62+
- RFC
63+
[https://github.com/graphql/graphql-spec/pull/1127](https://github.com/graphql/graphql-spec/pull/1127)
64+
- Benjie, we discussed this in a previous meeting. Since then we merged the
65+
underlying changes by Lee Byron
66+
- Benjie, what should happen when you have a subscription and you get an error
67+
that happens on the underlying stream. This would be the stream-iterator
68+
throwing an error.
69+
- Benjie, currently the error gets re-thrown which is very different from how
70+
GraphQL currently behaves as we normally return GraphQLErrors with a 200
71+
status code
72+
- Benjie, rethrowing → yielding a response with errors contained within
73+
- Martin, this would remove the last place that throws errors in GraphQL-JS
74+
right?
75+
- Benjie, yes, apart from edge-cases like non-validated schema-usage
76+
- Martin, I think this is a good change then. In Kotlin this is a big pain,
77+
having deterministic data structures would be a good change
78+
- Michael, We wouldn’t prescribe a fixed test for the error, would we?
79+
- Benjie, no, just like we don’t for any other error
80+
- Benjie, the main question here is to move this to RFC 1
81+
- We meet all of the criteria for stage 1
82+
- Michael, Yes! The current behaviour is not the user expected behaviour
83+
- **Decision**: We move this to RFC 1
84+
85+
## Add ‘extensions’ to request
86+
87+
- RFC
88+
[https://github.com/graphql/graphql-spec/pull/976](https://github.com/graphql/graphql-spec/pull/976)
89+
- Benjie, Should we move it to RFC 3 as the feedback is addressed
90+
- Benjie, As Lee is not here I’ll skip this until next month
91+
92+
## Defer/stream update
93+
94+
- Editorial change for Path:
95+
[https://github.com/graphql/graphql-spec/pull/1129](https://github.com/graphql/graphql-spec/pull/1129)
96+
- Spec edits for Section 3:
97+
[https://github.com/graphql/graphql-spec/pull/1132](https://github.com/graphql/graphql-spec/pull/1132)
98+
- Rob, The above PR’s need feedback. One other thing I’ve done since the last
99+
meeting is reaching out to authors of GraphQL clients to have feedback on the
100+
response format.
101+
- Rob, Kinda wanna get one last confirmation that the new response format is
102+
good! Please review the spec edits and editorial PR
103+
- Rob, Created a new PR that only edits section three so we can review it piece
104+
by piece.
105+
- Rob, This has all been implemented in GraphQL.JS - there haven’t been any
106+
proposed changes to this format since June 2023. The execution changes have
107+
settled as well.
108+
- Benjie, is the plan to do both defer and stream side by side (referencing an
109+
earlier plan to first get in defer and then stream)
110+
- Rob, that was discussed a few times but we never settled on a decision there.
111+
This goes forward with both stream and defer. The execution algorithm for
112+
stream isn't there yet.
113+
- Benjie, I think that’s the right decision so we don’t have to change things to
114+
defer because we find problems with stream later.
115+
- Benjie, is there a reason you put the argument for steam in that order
116+
- Rob, no
117+
- **Call to action**: Review the PRs
118+
119+
## Implementations may not deprecate a field that the interface hasn't deprecated
120+
121+
- RFC
122+
[https://github.com/graphql/graphql-spec/pull/1053](https://github.com/graphql/graphql-spec/pull/1053)
123+
- Benjie, This has broad approval and Lee suggested some wording tweaks
124+
- Benjie, For now we’ll leave this be as Stephen has requested changes.
125+
126+
## Fix CoerceArgumentValues()' hasValue
127+
128+
- RFC
129+
[https://github.com/graphql/graphql-spec/pull/1056](https://github.com/graphql/graphql-spec/pull/1056)
130+
- Benjie, There’s a bad hasValue check in the specification. We aren’t
131+
accounting for the argumentValue being a variable, we set hasValue to true
132+
when there is a variable however this variable could not have been specified
133+
- Jovi believes Benjie is 100% correct
134+
- Benjie, can we move this to RFC2? Everyone is scratching their head so…. We’ll
135+
bring it back next time.
136+
- **Call To Action**: provide reviews on
137+
[https://github.com/graphql/graphql-spec/pull/1056](https://github.com/graphql/graphql-spec/pull/1056)
138+
139+
## Be explicit about list coercion
140+
141+
- RFC
142+
[https://github.com/graphql/graphql-spec/pull/1058](https://github.com/graphql/graphql-spec/pull/1058)
143+
- Benije, this is a bug in the GraphQL Spec. The issue happens when we provide a
144+
default value to the middle of a nested argument value.
145+
- Should we push this to RFC2?
146+
- Resolution of challenge? Yes
147+
- Compliant implementation? Yes
148+
- Consensus? Not yet
149+
- **Call To Action**: provide reviews on
150+
[https://github.com/graphql/graphql-spec/pull/1058](https://github.com/graphql/graphql-spec/pull/1058)

0 commit comments

Comments
 (0)