Add notes from 2023-12 WG (#1461)

Author: benjie

notes/2023/2023-12.md

@@ -0,0 +1,131 @@
+# GraphQL WG Notes - December 2023
+
+**Watch the replays:**
+[GraphQL Working Group Meetings on YouTube](https://www.youtube.com/playlist?list=PLP1igyLx8foH30_sDnEZnxV_8pYW3SDtb)
+
+# Primary
+
+Agenda:
+https://github.com/graphql/graphql-wg/blob/main/agendas/2023/12-Dec/07-wg-primary.md
+
+## Determine volunteers for note taking (1m, Benjie)
+
+- Alex Reilly
+
+## Review agenda (2m, Benjie)
+
+- Done
+
+## Updates from the group formerly known as the Client Controlled Nullability WG (5m, Alex)
+
+- CCN is on hold, replaced by True Nullability
+- CCN WG is now “Nullability WG”
+- Alex: should we remove the feature from GraphQL-js?
+- Ivan: provide in PR a strong reason why flag is being removed, then remove it.
+  It’s good to clean up failed experiments. We should probably clean up some
+  others too.
+
+## Subcommittee to work on standardizing distributed schemas (15m, Jeff)
+
+- There has been a lot of new excitement across the community around
+  standardizing on an approach for working with distributed schemas, ranging
+  from Open Federation to Fusion
+- We (Apollo) are excited about these developments, and are looking forward to
+  working with others on this standardization approach
+- We haven't seen the afore mentioned standardization efforts be brought to the
+  Working Group yet, so we'd like to get the ball rolling and start discussions
+- Should we start
+  the[ composite schema](https://github.com/graphql/composite-schemas-wg)
+  subcommittee back up, to collaborate more closely? Or would folks like to
+  explore an alternative approach?
+  - Benjie reopened composite schema working group
+- Regardless, let's get the discussions going - super exciting!
+- Needed less time than expected, was able to clarify issues prior to the
+  meeting
+
+## Review previous meeting's action items (30m, Benjie)
+
+- [#1345](https://github.com/graphql/graphql-wg/issues/1345) - everyone review
+  default value validation
+  - Sufficient review time has
+    elapsed;[ RFC](https://github.com/graphql/graphql-spec/pull/793) is at stage
+    2 already - needs GraphQL.js merge for stage 3
+  - No objections, RFC moves forward
+- [#695](https://github.com/graphql/graphql-wg/issues/695) - no @skip/@include
+  on subscriptions - raise GraphQL.js PR
+  - [GraphQL.js PR](https://github.com/graphql/graphql-js/pull/3974) raised
+  - Can we bump[ RFC](https://github.com/graphql/graphql-spec/pull/860) to RFC2?
+  - No objections, moves forward to RFC2
+- [#1331](https://github.com/graphql/graphql-wg/issues/1331) - if interface
+  field deprecated, then object field should be deprecated
+  - [Spec PR](https://github.com/graphql/graphql-spec/pull/1053)
+    and[ GraphQL.js PR](https://github.com/graphql/graphql-js/pull/3986) raised
+  - Advance to RFC1?
+  - No objections, RFC moves forward
+- [#1336](https://github.com/graphql/graphql-wg/issues/1336) - coercing variable
+  values in lists; clarify spec text
+  - Discussed December 2022, but the issue was misinterpreted; it relates to
+    variables inside lists, not in arguments directly
+  - Spec editorial
+    PR:[ fix bug in list coercion example table](https://github.com/graphql/graphql-spec/pull/1057/files)
+  - Agenda item below: "Detail variables in list input coercion rules"
+  - Concerns that people may have implemented GraphQL engines incorrectly based
+    on the example provided rather than the language as the spec
+  - PR will be left open another week so people can respond
+- [#1414](https://github.com/graphql/graphql-wg/issues/1414) - example of
+  executing selection set serially, readers expect an operation; clarify
+  - Spec editorial
+    PR:[ define "selection set" and clarify examples in section 6](https://github.com/graphql/graphql-spec/pull/1032)
+  - Previously didn’t have a definition of what a selection set is
+  - Looking for approval from a few TSC members before merging
+- [#1337](https://github.com/graphql/graphql-wg/issues/1337) - forbid nullable
+  variable with default in non-nullable position
+  - Agenda item below: "Introduce Strict and Legacy All Variable Usages Are
+    Allowed validation rules"
+  - Meets criteria for RFC1, moves forward
+- [#1413](https://github.com/graphql/graphql-wg/issues/1413) - close all aging
+  action items
+  - [Stale closed items](https://github.com/graphql/graphql-wg/issues?q=is%3Aissue+is%3Aclosed+sort%3Aupdated-desc+label%3Astale+)
+  - Note: not all items closed were "action items"
+- [All open action items (by last update)](https://github.com/graphql/graphql-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Action+item+%3Aclapper%3A%22+sort%3Aupdated-desc)
+- [All open action items (by meeting)](https://github.com/graphql/graphql-wg/projects?type=classic&query=is%3Aopen+sort%3Aupdated-desc)
+
+## Fix bug in CoerceArgumentValues() algorithm (10m, Benjie)
+
+- [Spec PR](https://github.com/graphql/graphql-spec/pull/1056)
+- No GraphQL.js PR needed, GraphQL.js already implements the correct behavior
+- Spec bug: RFC process, or editorial?
+- Walked through the Spec PR
+- Graphql.js and graphql.net don’t suffer from this bug. Their implementations
+  do not strictly follow the text of the spec.
+- Moves forward to RFC1.
+
+## Detail variables in list input coercion rules (15m, Benjie)
+
+- [Spec PR](https://github.com/graphql/graphql-spec/pull/1058)
+- GraphQL.js already implements the correct behavior?
+- Previously discussed (but incorrectly interpreted) in December
+  2022:[ https://github.com/graphql/graphql-wg/blob/main/notes/2022/2022-12.md?rgh-link-date=2023-07-08T08%3A09%3A10Z#field-error-resulting-from-insufficient-validation-of-variables-15m-benjie](https://github.com/graphql/graphql-wg/blob/main/notes/2022/2022-12.md?rgh-link-date=2023-07-08T08%3A09%3A10Z#field-error-resulting-from-insufficient-validation-of-variables-15m-benjie)
+- Not really changing behavior, just defining the status quo... Editorial, or
+  RFC process?
+- Moving to RFC1.
+- Benjie: Has anyone been bitten by this issue?
+  - Matt: Yes, but most of my product people don’t use lists. This feature is
+    underused, so it’s also under-specced.
+
+## Introduce Strict and Legacy All Variable Usages Are Allowed validation rules (15m, Benjie)
+
+- [Spec PR](https://github.com/graphql/graphql-spec/pull/1059)
+- Aim: before I go about implementing this in GraphQL.js, are we agreed this is
+  the right solution? RFC1?
+- Question: should we enable the new algorithm by default in the next major bump
+  of GraphQL.js, and enable users to opt-in to the old version if they need to?
+- Reviewed Spec PR
+- We need a good migration story where we make it opt in one release, and then
+  opt out the next release
+- Michael: opt-in/out on a per-request basis (e.g. via a header)
+- It’s important that all existing queries continue to work against an existing
+  server as its schema evolves
+- Moved to RFC1
+- Looking for an alternative solution, none brought up in the meeting other than
+  doing nothing and allowing the bug to continue to exist