Add notes from January WG

notes/2025/2025-01.md

@@ -0,0 +1,150 @@
+# GraphQL WG Notes - January 2025
+
+**Watch the replays:**
+[GraphQL Working Group Meetings on YouTube](https://www.youtube.com/playlist?list=PLP1igyLx8foH30_sDnEZnxV_8pYW3SDtb)
+
+Agenda:
+[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)
+
+## TSC Election update
+
+- Issue:
+  [https://github.com/graphql/graphql-wg/issues/1612](https://github.com/graphql/graphql-wg/issues/1612)
+- We’ll be closing the application process 10th of January 2025
+
+## TSC GitHub permissions
+
+- Some TSC members have ownership permissions
+- Rather than every TSC member having ownership permissions
+- Let’s save it for a different time as Lee is not here
+
+## GraphQLConf 2025
+
+- Amsterdam September 8 - 10 2025
+- We want more community - WG involvement
+- We want you to attend, tell us why and how we can help you
+- There might be a working group track during what’s normally the unconference
+  day
+  - Working group leaders for composite schemas, … would do a talk and have
+    discussions
+  - Being in the same room can spark new ideas
+  - Michael, good idea, having dedicated discussion time would be a great change
+  - Martin, how would this work? Would it be interested people or the general
+    audience?
+  - Martin, workshops might be better to spark discussion
+  - Michael, I thought more about user group style, champions talk about the
+    topics and the current state. Then after you have time to mingle and talk to
+    the people.
+  - Michael, the main difference with the regular talk format is that it isn’t
+    packed, we have dedicated discussion time.
+  - Benjie, my idea is the champions have talks, there will be some tables and
+    people can approach the tables that interest them (based on
+    topics/subtopics). Discussions of 8-10 people, then people from each table
+    can surface the ideas from their table to the general group.
+  - Benjie, the audience is wider than the working groups, it will be a narrower
+    group than the conference audience but interested people that touch on these
+    topics, like folks writing GraphQL clients.
+  - Jeff, there was also talk about doing working sessions
+  - Benjie, introducing a slightly wider audience is the goal, this could give
+    us an opportunity for a lot more feedback
+  - Michael, aren’t these people involved in the working groups already? For
+    example in Microsoft conferences product managers invite you to give
+    feedback on their spare time.
+  - Benjie, if people have more thoughts or ideas or know what works and what
+    does not please reach out
+- Benjie: is there anyone we should include for various topics, like subject
+  matter experts that work on GraphQL clients. Anyone eager to MC, …?
+  - Martin, what is the best way to reach out?
+  - Benjie, Discord in the graphqlconf channel
+
+## Changing error handling of subscription streams
+
+- RFC
+  [https://github.com/graphql/graphql-spec/pull/1127](https://github.com/graphql/graphql-spec/pull/1127)
+- Benjie, we discussed this in a previous meeting. Since then we merged the
+  underlying changes by Lee Byron
+- Benjie, what should happen when you have a subscription and you get an error
+  that happens on the underlying stream. This would be the stream-iterator
+  throwing an error.
+- Benjie, currently the error gets re-thrown which is very different from how
+  GraphQL currently behaves as we normally return GraphQLErrors with a 200
+  status code
+- Benjie, rethrowing → yielding a response with errors contained within
+- Martin, this would remove the last place that throws errors in GraphQL-JS
+  right?
+- Benjie, yes, apart from edge-cases like non-validated schema-usage
+- Martin, I think this is a good change then. In Kotlin this is a big pain,
+  having deterministic data structures would be a good change
+- Michael, We wouldn’t prescribe a fixed test for the error, would we?
+- Benjie, no, just like we don’t for any other error
+- Benjie, the main question here is to move this to RFC 1
+  - We meet all of the criteria for stage 1
+- Michael, Yes! The current behaviour is not the user expected behaviour
+- **Decision**: We move this to RFC 1
+
+## Add ‘extensions’ to request
+
+- RFC
+  [https://github.com/graphql/graphql-spec/pull/976](https://github.com/graphql/graphql-spec/pull/976)
+- Benjie, Should we move it to RFC 3 as the feedback is addressed
+- Benjie, As Lee is not here I’ll skip this until next month
+
+## Defer/stream update
+
+- Editorial change for Path:
+  [https://github.com/graphql/graphql-spec/pull/1129](https://github.com/graphql/graphql-spec/pull/1129)
+- Spec edits for Section 3:
+  [https://github.com/graphql/graphql-spec/pull/1132](https://github.com/graphql/graphql-spec/pull/1132)
+- Rob, The above PR’s need feedback. One other thing I’ve done since the last
+  meeting is reaching out to authors of GraphQL clients to have feedback on the
+  response format.
+- Rob, Kinda wanna get one last confirmation that the new response format is
+  good! Please review the spec edits and editorial PR
+- Rob, Created a new PR that only edits section three so we can review it piece
+  by piece.
+- Rob, This has all been implemented in GraphQL.JS - there haven’t been any
+  proposed changes to this format since June 2023. The execution changes have
+  settled as well.
+- Benjie, is the plan to do both defer and stream side by side (referencing an
+  earlier plan to first get in defer and then stream)
+- Rob, that was discussed a few times but we never settled on a decision there.
+  This goes forward with both stream and defer. The execution algorithm for
+  stream isn't there yet.
+- Benjie, I think that’s the right decision so we don’t have to change things to
+  defer because we find problems with stream later.
+- Benjie, is there a reason you put the argument for steam in that order
+- Rob, no
+- **Call to action**: Review the PRs
+
+## Implementations may not deprecate a field that the interface hasn't deprecated
+
+- RFC
+  [https://github.com/graphql/graphql-spec/pull/1053](https://github.com/graphql/graphql-spec/pull/1053)
+- Benjie, This has broad approval and Lee suggested some wording tweaks
+- Benjie, For now we’ll leave this be as Stephen has requested changes.
+
+## Fix CoerceArgumentValues()' hasValue
+
+- RFC
+  [https://github.com/graphql/graphql-spec/pull/1056](https://github.com/graphql/graphql-spec/pull/1056)
+- Benjie, There’s a bad hasValue check in the specification. We aren’t
+  accounting for the argumentValue being a variable, we set hasValue to true
+  when there is a variable however this variable could not have been specified
+- Jovi believes Benjie is 100% correct
+- Benjie, can we move this to RFC2? Everyone is scratching their head so…. We’ll
+  bring it back next time.
+- **Call To Action**: provide reviews on
+  [https://github.com/graphql/graphql-spec/pull/1056](https://github.com/graphql/graphql-spec/pull/1056)
+
+## Be explicit about list coercion
+
+- RFC
+  [https://github.com/graphql/graphql-spec/pull/1058](https://github.com/graphql/graphql-spec/pull/1058)
+- Benije, this is a bug in the GraphQL Spec. The issue happens when we provide a
+  default value to the middle of a nested argument value.
+- Should we push this to RFC2?
+  - Resolution of challenge? Yes
+  - Compliant implementation? Yes
+  - Consensus? Not yet
+- **Call To Action**: provide reviews on
+  [https://github.com/graphql/graphql-spec/pull/1058](https://github.com/graphql/graphql-spec/pull/1058)