diff --git a/notes/2025/2025-01.md b/notes/2025/2025-01.md new file mode 100644 index 00000000..a35a5994 --- /dev/null +++ b/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)