├── agendas ├── 2025 │ ├── 11-Nov │ │ └── 27-otel-wg-november-2025.md │ ├── 12-Dec │ │ └── 25-otel-wg-december-2025.md │ ├── 09-Sep │ │ └── 25-otel-wg-september-2025.md │ ├── 08-Aug │ │ └── 28-otel-wg-august-2025.md │ ├── 07-Jul │ │ └── 24-otel-wg-july-2025.md │ ├── 05-May │ │ └── 22-otel-wg-may-2025.md │ ├── 10-Oct │ │ └── 23-otel-wg-october-2025.md │ ├── 06-Jun │ │ └── 26-otel-wg-june-2025.md │ └── 04-Apr │ │ └── 24-otel-wg-april-2025.md ├── 2026 │ ├── 03-Mar │ │ └── 26-otel-wg-march-2026.md │ ├── 02-Feb │ │ └── 26-otel-wg-february-2026.md │ └── 01-Jan │ │ └── 22-otel-wg-january-2026.md └── README.md ├── .gitignore ├── .prettierignore ├── cspell.yml ├── .github ├── ISSUE_TEMPLATE │ └── action-item.md ├── PULL_REQUEST_TEMPLATE │ └── agenda-attendance.md └── workflows │ └── wgutils-automerge.yml ├── package.json ├── rfcs └── README.md ├── notes ├── 2025 │ ├── summary-2025-05-22.md │ ├── summary-2025-04-24.md │ ├── summary-2025-10-23.md │ ├── 2025-04-24.md │ ├── summary-2025-09-25.md │ ├── summary-2025-08-28.md │ ├── summary-2025-06-26.md │ └── summary-2025-07-24.md └── README.md ├── wg.config.js └── README.md /agendas/2025/11-Nov/27-otel-wg-november-2025.md: -------------------------------------------------------------------------------- 1 | Cancelled due to Thanksgiving 2 | -------------------------------------------------------------------------------- /agendas/2025/12-Dec/25-otel-wg-december-2025.md: -------------------------------------------------------------------------------- 1 | Meeting canceled due to the winter break. 2 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.swp 2 | *~ 3 | .*.haste_cache.* 4 | .DS_Store 5 | npm-debug.log 6 | /build 7 | /public 8 | /gh-pages 9 | /node_modules 10 | yarn.lock 11 | package-lock.json 12 | -------------------------------------------------------------------------------- /.prettierignore: -------------------------------------------------------------------------------- 1 | *.swp 2 | *~ 3 | .*.haste_cache.* 4 | .DS_Store 5 | npm-debug.log 6 | /build 7 | /changelogs 8 | /out 9 | /gh-pages 10 | /node_modules 11 | /package.json 12 | -------------------------------------------------------------------------------- /cspell.yml: -------------------------------------------------------------------------------- 1 | language: en-US 2 | ignoreRegExpList: 3 | # Posessives 4 | - /[a-z]{2,}'s/ 5 | words: 6 | # Terms of art 7 | - endianness 8 | - interoperation 9 | - monospace 10 | - openwebfoundation 11 | - parallelization 12 | - structs 13 | - subselection 14 | # Software 15 | - ical 16 | # Fictional characters / examples 17 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/action-item.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Meeting Action Item 3 | about: Template for action items recommended during subcommittee meetings. 4 | labels: "Action item :clapper:" 5 | --- 6 | 7 | 8 | 9 | - assignee(s): 10 | - source: 11 | 12 | --- 13 | 14 | _Note: Action Item issues are reviewed and closed during Working Group 15 | meetings._ 16 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "graphql-subcommittee", 3 | "private": true, 4 | "license": "OWFa-1.0", 5 | "scripts": { 6 | "gen-agenda": "wgutils agenda gen", 7 | "test:spellcheck": "cspell \"**/*.md\"", 8 | "format": "prettier --write \"**/*.{md,yml,yaml,json}\"", 9 | "format:check": "prettier --check \"**/*.{md,yml,yaml,json}\"" 10 | }, 11 | "devDependencies": { 12 | "cspell": "5.9.1", 13 | "prettier": "^2.6.2" 14 | }, 15 | "prettier": { 16 | "proseWrap": "always" 17 | }, 18 | "dependencies": { 19 | "wgutils": "^1.3.0" 20 | } 21 | } 22 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE/agenda-attendance.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Meeting Agenda or Attendance 3 | about: 4 | Template for adding agenda or attendance to an upcoming subcommittee meeting. 5 | labels: "Agenda :hand:" 6 | --- 7 | 8 | 24 | -------------------------------------------------------------------------------- /agendas/README.md: -------------------------------------------------------------------------------- 1 | # Agendas 2 | 3 | An agenda contains details of when a subcommittee meeting occurs, how to access 4 | it, who will be attending and what the topics to be covered are. 5 | 6 | Agendas files are always named in `YYYY-MM-DD.md` format, and should be located 7 | in a folder representing the year. 8 | 9 | To request participation in an upcoming meeting, please send a pull request by 10 | editing the relevant meeting agenda. 11 | 12 | After a meeting, notes should be uploaded to the reciprocal file in 13 | [the notes folder](../notes). 14 | 15 | Meetings are recorded, and they can be viewed on the GraphQL Foundation's 16 | YouTube channel: 17 | 18 | https://www.youtube.com/channel/UCERcwLeheOXp_u61jEXxHMA/videos 19 | 20 | There may or may not be a playlist specifically for this subcommittee; if there 21 | is one it can be found here: 22 | 23 | https://www.youtube.com/channel/UCERcwLeheOXp_u61jEXxHMA/playlists 24 | -------------------------------------------------------------------------------- /rfcs/README.md: -------------------------------------------------------------------------------- 1 | # RFC (request for comments) Working Documents 2 | 3 | The files found here are collaborative notes exploring various proposals for advancing this subcommittee. Documents included in this directory imply no specific approval or support nor are any proposals required to create a document here. 4 | 5 | ## Disclaimers 6 | 7 | * Documents included in this directory imply no specific approval or support for inclusion in the GraphQL spec or other GraphQL projects. 8 | * Documents here may be historical or out of date. 9 | * An RFC may be active without being documented here; there is no requirement to add RFCs here. 10 | 11 | ## Contributing 12 | 13 | Pull requests are encouraged. New documents and other non-destructive changes may be merged with a low degree of scrutiny and minimal review. 14 | 15 | That said, please follow these suggestions: 16 | 17 | * New proposals should be presented in a [working group meeting](../agendas). Submitting a document here is not sufficient or required to introduce a new proposal. 18 | * Favor documents which define a problem and explore a solution space rather than propose a specific change. The intent of documents found here are to help ask and answer questions to build confidence and advance an RFC. 19 | -------------------------------------------------------------------------------- /notes/README.md: -------------------------------------------------------------------------------- 1 | ## Notes for all past subcommittee meetings are kept here. 2 | 3 | Interested in 4 | [taking notes](https://github.com/graphql/graphql-wg#volunteer-to-take-notes) 5 | for a meeting? Sign up for the next session! 6 | 7 | Notes files mirror the file structure of the agendas; namely they should be in 8 | `YYYY/YYYY-MM-DD.md` files to match the date that the meeting took place. 9 | 10 | All notes files should begin with the following format: 11 | 12 | ```md 13 | # GraphQL OTel WG Notes - 14 | 15 | **Watch the replay:** 16 | [GraphQL Working Group Meetings on YouTube](https://www.youtube.com/channel/UCERcwLeheOXp_u61jEXxHMA/videos) 17 | 18 | ## Agenda 19 | 20 | 21 | ``` 22 | 23 | When adding notes: use H2 (`##`) to indicate new topics, use bullet points to 24 | track discussion, try and keep track of who said each thing, and keep in mind 25 | this is not a transcription - everything is assumed to be 26 | paraphrased/simplified. When inserting meta-notes (notes on the notes), use 27 | curly braces to avoid conflicts with markdown - e.g. `{inaudible}`, 28 | `{could not keep up with discussion}`, or `{time - 22:03}` 29 | 30 | It's beneficial to insert timestamps periodically throughout the notes as it 31 | allows for easier lookup of the discussion in the video on YouTube. 32 | 33 | Actions should be recorded in the following format: 34 | 35 | ``` 36 | - : **ACTION - **: 37 | ``` 38 | 39 | For example: 40 | 41 | - Lee: **ACTION - Benjie** Write an implementation in GraphQL.js 42 | 43 | Sometimes ACTIONS are inferred rather than explicit, try and write down the 44 | inferred action as best you can - it's okay to omit the speaker, the critical 45 | thing is to have an assignee and a brief description of the assignment. 46 | 47 | Sometimes actions are on everyone; in these cases `**ACTION - everyone**` is 48 | appropriate, but when filing the action item it should be assigned on GitHub to 49 | the champion for that topic. 50 | -------------------------------------------------------------------------------- /.github/workflows/wgutils-automerge.yml: -------------------------------------------------------------------------------- 1 | name: Agenda auto-merge 2 | 3 | # First, enable branch protections, and in particular ensure the EasyCLA check is required. 4 | # Then, uncomment the next 3 lines: 5 | on: 6 | pull_request_target: 7 | types: [synchronize, opened, reopened] 8 | 9 | permissions: 10 | contents: write 11 | pull-requests: read 12 | checks: read 13 | 14 | jobs: 15 | validate-and-merge: 16 | if: ${{ github.event.pull_request.base.ref == 'main' }} 17 | runs-on: ubuntu-latest 18 | 19 | steps: 20 | # SECURITY: it's critical we do not check out the source pull request! 21 | - name: Checkout the main branch 22 | uses: actions/checkout@v3 23 | with: 24 | ref: main 25 | 26 | # We need wgutils to be installed 27 | - run: yarn install 28 | 29 | - name: Wait for checks to pass 30 | env: 31 | GH_TOKEN: ${{ github.token }} 32 | run: | 33 | # Give 15 seconds for any checks to register 34 | sleep 15 35 | 36 | # Wait for checks to pass 37 | gh pr checks ${{ github.event.pull_request.number }} --fail-fast --watch --required 2>&1 || true 38 | # Now get the result in JSON 39 | CHECKS_OUTPUT="$(gh pr checks ${{ github.event.pull_request.number }} --required --json bucket --jq 'map(.bucket == "pass") | all' 2>&1 || true)" 40 | 41 | if echo "$CHECKS_OUTPUT" | grep -q "no required checks reported"; then 42 | echo "Not required: $CHECKS_OUTPUT" 43 | elif [[ "$CHECKS_OUTPUT" == "true" ]]; then 44 | echo "$CHECKS_OUTPUT" 45 | else 46 | echo "PR state failed? $CHECKS_OUTPUT" 47 | exit 1 48 | fi 49 | 50 | - name: Automerge if wgutils approves 51 | env: 52 | GH_TOKEN: ${{ github.token }} 53 | run: | 54 | if yarn wgutils can-automerge "${{ github.event.pull_request.number }}" "${{ github.event.pull_request.head.sha }}"; then 55 | gh pr merge "${{ github.event.pull_request.number }}" --squash --auto --match-head-commit "${{ github.event.pull_request.head.sha }}" 56 | fi 57 | -------------------------------------------------------------------------------- /agendas/2026/03-Mar/26-otel-wg-march-2026.md: -------------------------------------------------------------------------------- 1 | | This is an open meeting: To attend, edit and PR this file. (Edit: ✎ above, or press "e") | 2 | | ---------------------------------------------------------------------------------------- | 3 | 4 | # OTel WG — March 2026 5 | 6 | - **Date & Time**: [March 26, 2026, 10:00 – 11:00 AM PDT](https://www.timeanddate.com/worldclock/converter.html?iso=20260326T170000&p1=224&p2=179&p3=136&p4=268&p5=367&p6=438&p7=248&p8=240) 7 | - View the [calendar][], or subscribe ([Google Calendar][], [ical file][]). 8 | - _Please Note:_ The date or time may change. Please check this agenda the 9 | week of the meeting to confirm. While we try to keep all calendars accurate, 10 | this agenda document is the source of truth. 11 | - **Video Conference Link**: https://zoom.us/j/93594710848 12 | - _Password:_ otel 13 | - **Live Notes**: [Live Notes][] 14 | 15 | [calendar]: https://calendar.google.com/calendar/embed?src=linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com 16 | [google calendar]: https://calendar.google.com/calendar?cid=bGludXhmb3VuZGF0aW9uLm9yZ19pazc5dDl1dWoycDMyaTNyMjAzZGd2NW1vOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t 17 | [ical file]: https://calendar.google.com/calendar/ical/linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com/public/basic.ics 18 | [live notes]: https://docs.google.com/document/d/1f8RdYS_avbBcH1AGa1wMGYxrGVS8_HKfMAB8gjQ8ZfE/edit?usp=sharing 19 | 20 | ## Attendees 21 | 22 | 23 | | Name | GitHub | Organization | Location | 24 | | :--------------- | :------------ | :----------------- | :-------------------- | 25 | 26 | 27 | ## Agenda 28 | 29 | 1. Agree to Membership Agreement, Participation & Contribution Guidelines and Code of Conduct (1m, Host) 30 | - [Specification Membership Agreement](https://github.com/graphql/foundation) 31 | - [Participation Guidelines](https://github.com/graphql/graphql-wg#participation-guidelines) 32 | - [Contribution Guide](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md) 33 | - [Code of Conduct](https://github.com/graphql/foundation/blob/master/CODE-OF-CONDUCT.md) 34 | - Meetings are [published to YouTube](https://www.youtube.com/@GraphQLFoundation/videos) and we may use LLM/AI summary tools 35 | 1. Introduction of attendees (5m, Host) 36 | 1. Determine volunteers for note taking (1m, Host) 37 | 1. Review agenda (2m, Host) 38 | 1. Check for [ready for review agenda items](https://github.com/graphql/otel-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Ready+for+review+%F0%9F%99%8C%22+sort%3Aupdated-desc) (5m, Host) 39 | 1. Reminder: [grants available for key initiatives](https://graphql.org/community/foundation/community-grant/) (1m, Host) 40 | -------------------------------------------------------------------------------- /agendas/2026/02-Feb/26-otel-wg-february-2026.md: -------------------------------------------------------------------------------- 1 | | This is an open meeting: To attend, edit and PR this file. (Edit: ✎ above, or press "e") | 2 | | ---------------------------------------------------------------------------------------- | 3 | 4 | # OTel WG — February 2026 5 | 6 | - **Date & Time**: [February 26, 2026, 10:00 – 11:00 AM PST](https://www.timeanddate.com/worldclock/converter.html?iso=20260226T180000&p1=224&p2=179&p3=136&p4=268&p5=367&p6=438&p7=248&p8=240) 7 | - View the [calendar][], or subscribe ([Google Calendar][], [ical file][]). 8 | - _Please Note:_ The date or time may change. Please check this agenda the 9 | week of the meeting to confirm. While we try to keep all calendars accurate, 10 | this agenda document is the source of truth. 11 | - **Video Conference Link**: https://zoom.us/j/93594710848 12 | - _Password:_ otel 13 | - **Live Notes**: [Live Notes][] 14 | 15 | [calendar]: https://calendar.google.com/calendar/embed?src=linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com 16 | [google calendar]: https://calendar.google.com/calendar?cid=bGludXhmb3VuZGF0aW9uLm9yZ19pazc5dDl1dWoycDMyaTNyMjAzZGd2NW1vOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t 17 | [ical file]: https://calendar.google.com/calendar/ical/linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com/public/basic.ics 18 | [live notes]: https://docs.google.com/document/d/1f8RdYS_avbBcH1AGa1wMGYxrGVS8_HKfMAB8gjQ8ZfE/edit?usp=sharing 19 | 20 | ## Attendees 21 | 22 | 23 | | Name | GitHub | Organization | Location | 24 | | :--------------- | :------------ | :----------------- | :-------------------- | 25 | 26 | 27 | ## Agenda 28 | 29 | 1. Agree to Membership Agreement, Participation & Contribution Guidelines and Code of Conduct (1m, Host) 30 | - [Specification Membership Agreement](https://github.com/graphql/foundation) 31 | - [Participation Guidelines](https://github.com/graphql/graphql-wg#participation-guidelines) 32 | - [Contribution Guide](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md) 33 | - [Code of Conduct](https://github.com/graphql/foundation/blob/master/CODE-OF-CONDUCT.md) 34 | - Meetings are [published to YouTube](https://www.youtube.com/@GraphQLFoundation/videos) and we may use LLM/AI summary tools 35 | 1. Introduction of attendees (5m, Host) 36 | 1. Determine volunteers for note taking (1m, Host) 37 | 1. Review agenda (2m, Host) 38 | 1. Check for [ready for review agenda items](https://github.com/graphql/otel-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Ready+for+review+%F0%9F%99%8C%22+sort%3Aupdated-desc) (5m, Host) 39 | 1. Reminder: [grants available for key initiatives](https://graphql.org/community/foundation/community-grant/) (1m, Host) 40 | -------------------------------------------------------------------------------- /agendas/2026/01-Jan/22-otel-wg-january-2026.md: -------------------------------------------------------------------------------- 1 | | This is an open meeting: To attend, edit and PR this file. (Edit: ✎ above, or press "e") | 2 | | ---------------------------------------------------------------------------------------- | 3 | 4 | # OTel WG — January 2026 5 | 6 | - **Date & Time**: [January 22, 2026, 10:00 – 11:00 AM PST](https://www.timeanddate.com/worldclock/converter.html?iso=20260122T180000&p1=224&p2=179&p3=136&p4=268&p5=367&p6=438&p7=248&p8=240) 7 | - View the [calendar][], or subscribe ([Google Calendar][], [ical file][]). 8 | - _Please Note:_ The date or time may change. Please check this agenda the 9 | week of the meeting to confirm. While we try to keep all calendars accurate, 10 | this agenda document is the source of truth. 11 | - **Video Conference Link**: https://zoom.us/j/93594710848 12 | - _Password:_ otel 13 | - **Live Notes**: [Live Notes][] 14 | 15 | [calendar]: https://calendar.google.com/calendar/embed?src=linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com 16 | [google calendar]: https://calendar.google.com/calendar?cid=bGludXhmb3VuZGF0aW9uLm9yZ19pazc5dDl1dWoycDMyaTNyMjAzZGd2NW1vOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t 17 | [ical file]: https://calendar.google.com/calendar/ical/linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com/public/basic.ics 18 | [live notes]: https://docs.google.com/document/d/1f8RdYS_avbBcH1AGa1wMGYxrGVS8_HKfMAB8gjQ8ZfE/edit?usp=sharing 19 | 20 | ## Attendees 21 | 22 | 23 | | Name | GitHub | Organization | Location | 24 | | :--------------- | :------------ | :----------------- | :-------------------- | 25 | | Valentin Cocaud | EmrsyMyrddin | The Guild | Nantes, FR | 26 | 27 | 28 | ## Agenda 29 | 30 | 1. Agree to Membership Agreement, Participation & Contribution Guidelines and Code of Conduct (1m, Host) 31 | - [Specification Membership Agreement](https://github.com/graphql/foundation) 32 | - [Participation Guidelines](https://github.com/graphql/graphql-wg#participation-guidelines) 33 | - [Contribution Guide](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md) 34 | - [Code of Conduct](https://github.com/graphql/foundation/blob/master/CODE-OF-CONDUCT.md) 35 | - Meetings are [published to YouTube](https://www.youtube.com/@GraphQLFoundation/videos) and we may use LLM/AI summary tools 36 | 1. Introduction of attendees (5m, Host) 37 | 1. Determine volunteers for note taking (1m, Host) 38 | 1. Review agenda (2m, Host) 39 | 1. Check for [ready for review agenda items](https://github.com/graphql/otel-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Ready+for+review+%F0%9F%99%8C%22+sort%3Aupdated-desc) (5m, Host) 40 | 1. Reminder: [grants available for key initiatives](https://graphql.org/community/foundation/community-grant/) (1m, Host) 41 | -------------------------------------------------------------------------------- /agendas/2025/09-Sep/25-otel-wg-september-2025.md: -------------------------------------------------------------------------------- 1 | | This is an open meeting: To attend, edit and PR this file. (Edit: ✎ above, or press "e") | 2 | | ---------------------------------------------------------------------------------------- | 3 | 4 | # OTel WG — September 2025 5 | 6 | - **Date & Time**: [September 25, 2025, 10:00 – 11:00 AM PDT](https://www.timeanddate.com/worldclock/converter.html?iso=20250925T170000&p1=224&p2=179&p3=136&p4=268&p5=367&p6=438&p7=248&p8=240) 7 | - View the [calendar][], or subscribe ([Google Calendar][], [ical file][]). 8 | - _Please Note:_ The date or time may change. Please check this agenda the 9 | week of the meeting to confirm. While we try to keep all calendars accurate, 10 | this agenda document is the source of truth. 11 | - **Video Conference Link**: https://zoom.us/j/93594710848 12 | - _Password:_ otel 13 | - **Live Notes**: [Live Notes][] 14 | 15 | [calendar]: https://calendar.google.com/calendar/embed?src=linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com 16 | [google calendar]: https://calendar.google.com/calendar?cid=bGludXhmb3VuZGF0aW9uLm9yZ19pazc5dDl1dWoycDMyaTNyMjAzZGd2NW1vOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t 17 | [ical file]: https://calendar.google.com/calendar/ical/linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com/public/basic.ics 18 | [live notes]: https://docs.google.com/document/d/1f8RdYS_avbBcH1AGa1wMGYxrGVS8_HKfMAB8gjQ8ZfE/edit?usp=sharing 19 | 20 | ## Attendees 21 | 22 | 23 | | Name | GitHub | Organization | Location | 24 | | :--------------- | :------------ | :----------------- | :-------------------- | 25 | | Pascal Senn (host)| pascalsenn | ChilliCream | Zurich, CH | 26 | | Valentin Cocaud | EmrysMyrddin | The Guild | France | 27 | | Rob Van Gennip | @ravangen | Shopify | Toronto, ON, CA | 28 | 29 | 30 | ## Agenda 31 | 32 | 1. Agree to Membership Agreement, Participation & Contribution Guidelines and Code of Conduct (1m, Host) 33 | - [Specification Membership Agreement](https://github.com/graphql/foundation) 34 | - [Participation Guidelines](https://github.com/graphql/graphql-wg#participation-guidelines) 35 | - [Contribution Guide](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md) 36 | - [Code of Conduct](https://github.com/graphql/foundation/blob/master/CODE-OF-CONDUCT.md) 37 | - Meetings are [published to YouTube](https://www.youtube.com/@GraphQLFoundation/videos) and we may use LLM/AI summary tools 38 | 1. Introduction of attendees (5m, Host) 39 | 1. Determine volunteers for note taking (1m, Host) 40 | 1. Review agenda (2m, Host) 41 | 1. Check for [ready for review agenda items](https://github.com/graphql/otel-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Ready+for+review+%F0%9F%99%8C%22+sort%3Aupdated-desc) (5m, Host) 42 | 1. Semantic Conventions for errors (15m, Host) 43 | -------------------------------------------------------------------------------- /agendas/2025/08-Aug/28-otel-wg-august-2025.md: -------------------------------------------------------------------------------- 1 | | This is an open meeting: To attend, edit and PR this file. (Edit: ✎ above, or press "e") | 2 | | ---------------------------------------------------------------------------------------- | 3 | 4 | # OTel WG — August 2025 5 | 6 | - **Date & Time**: [August 28, 2025, 10:00 – 11:00 AM PDT](https://www.timeanddate.com/worldclock/converter.html?iso=20250828T170000&p1=224&p2=179&p3=136&p4=268&p5=367&p6=438&p7=248&p8=240) 7 | - View the [calendar][], or subscribe ([Google Calendar][], [ical file][]). 8 | - _Please Note:_ The date or time may change. Please check this agenda the 9 | week of the meeting to confirm. While we try to keep all calendars accurate, 10 | this agenda document is the source of truth. 11 | - **Video Conference Link**: https://zoom.us/j/93594710848 12 | - _Password:_ otel 13 | - **Live Notes**: [Live Notes][] 14 | 15 | [calendar]: https://calendar.google.com/calendar/embed?src=linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com 16 | [google calendar]: https://calendar.google.com/calendar?cid=bGludXhmb3VuZGF0aW9uLm9yZ19pazc5dDl1dWoycDMyaTNyMjAzZGd2NW1vOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t 17 | [ical file]: https://calendar.google.com/calendar/ical/linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com/public/basic.ics 18 | [live notes]: https://docs.google.com/document/d/1f8RdYS_avbBcH1AGa1wMGYxrGVS8_HKfMAB8gjQ8ZfE/edit?usp=sharing 19 | 20 | ## Attendees 21 | 22 | 23 | | Name | GitHub | Organization | Location | 24 | | :---------------- | :------------ | :----------------- | :-------------------- | 25 | | Pascal Senn (host)| @pascalsenn | ChilliCream | Zurich, CH | 26 | | Eli Oshinsky | @eli0shin | PayPal | Baltimore, MD | 27 | | Brian Clozel | @bclozel | Spring at VMware | Lyon, FR | 28 | | Marco Costa | @marcotc | Datadog | Victoria, BC | 29 | | Rob Van Gennip | @ravangen | Shopify | Toronto, ON, CA | 30 | 31 | ## Agenda 32 | 33 | 1. Agree to Membership Agreement, Participation & Contribution Guidelines and Code of Conduct (1m, Host) 34 | - [Specification Membership Agreement](https://github.com/graphql/foundation) 35 | - [Participation Guidelines](https://github.com/graphql/graphql-wg#participation-guidelines) 36 | - [Contribution Guide](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md) 37 | - [Code of Conduct](https://github.com/graphql/foundation/blob/master/CODE-OF-CONDUCT.md) 38 | - Meetings are [published to YouTube](https://www.youtube.com/@GraphQLFoundation/videos) and we may use LLM/AI summary tools 39 | 1. Introduction of attendees (5m, Host) 40 | 1. Determine volunteers for note taking (1m, Host) 41 | 1. Review agenda (2m, Host) 42 | 1. Check for [ready for review agenda items](https://github.com/graphql/otel-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Ready+for+review+%F0%9F%99%8C%22+sort%3Aupdated-desc) (5m, Host) 43 | 1. Review PR #32 #33 #34 44 | -------------------------------------------------------------------------------- /agendas/2025/07-Jul/24-otel-wg-july-2025.md: -------------------------------------------------------------------------------- 1 | | This is an open meeting: To attend, edit and PR this file. (Edit: ✎ above, or press "e") | 2 | | ---------------------------------------------------------------------------------------- | 3 | 4 | # OTel WG — July 2025 5 | 6 | - **Date & Time**: [July 24, 2025, 10:00 – 11:00 AM PDT](https://www.timeanddate.com/worldclock/converter.html?iso=20250724T170000&p1=224&p2=179&p3=136&p4=268&p5=367&p6=438&p7=248&p8=240) 7 | - View the [calendar][], or subscribe ([Google Calendar][], [ical file][]). 8 | - _Please Note:_ The date or time may change. Please check this agenda the 9 | week of the meeting to confirm. While we try to keep all calendars accurate, 10 | this agenda document is the source of truth. 11 | - **Video Conference Link**: https://zoom.us/j/93594710848 12 | - _Password:_ otel 13 | - **Live Notes**: [Live Notes][] 14 | 15 | [calendar]: https://calendar.google.com/calendar/embed?src=linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com 16 | [google calendar]: https://calendar.google.com/calendar?cid=bGludXhmb3VuZGF0aW9uLm9yZ19pazc5dDl1dWoycDMyaTNyMjAzZGd2NW1vOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t 17 | [ical file]: https://calendar.google.com/calendar/ical/linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com/public/basic.ics 18 | [live notes]: https://docs.google.com/document/d/1f8RdYS_avbBcH1AGa1wMGYxrGVS8_HKfMAB8gjQ8ZfE/edit?usp=sharing 19 | 20 | ## Attendees 21 | 22 | 23 | | Name | GitHub | Organization | Location | 24 | | :---------------- | :------------ | :----------------- | :-------------------- | 25 | | Pascal Senn (Host)| @pascalsenn | ChilliCream | Zurich, CH | 26 | | Valentin Cocaud | @EmrysMyrddin | The Guild | Nantes, FR | 27 | | Eli Oshinsky | @eli0shin | PayPal | Baltimore, MD | 28 | | Marco Costa | @marcotc | Datadog | Victoria, BC, CA | 29 | | Rob Van Gennip | @ravangen | Shopify | Toronto, ON, CA | 30 | 31 | ## Agenda 32 | 33 | 1. Agree to Membership Agreement, Participation & Contribution Guidelines and Code of Conduct (1m, Host) 34 | - [Specification Membership Agreement](https://github.com/graphql/foundation) 35 | - [Participation Guidelines](https://github.com/graphql/graphql-wg#participation-guidelines) 36 | - [Contribution Guide](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md) 37 | - [Code of Conduct](https://github.com/graphql/foundation/blob/master/CODE-OF-CONDUCT.md) 38 | - Meetings are [published to YouTube](https://www.youtube.com/@GraphQLFoundation/videos) and we may use LLM/AI summary tools 39 | 1. Introduction of attendees (5m, Host) 40 | 1. Determine volunteers for note taking (1m, Host) 41 | 1. Review agenda (2m, Host) 42 | 1. Check for [ready for review agenda items](https://github.com/graphql/otel-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Ready+for+review+%F0%9F%99%8C%22+sort%3Aupdated-desc) (5m, Host) 43 | 1. Continue discussion on resolver spans (15m, Host) 44 | -------------------------------------------------------------------------------- /agendas/2025/05-May/22-otel-wg-may-2025.md: -------------------------------------------------------------------------------- 1 | | This is an open meeting: To attend, edit and PR this file. (Edit: ✎ above, or press "e") | 2 | | ---------------------------------------------------------------------------------------- | 3 | 4 | # OTel WG — May 2025 5 | 6 | - **Date & Time**: [May 22, 2025, 10:00 – 11:00 AM PDT](https://www.timeanddate.com/worldclock/converter.html?iso=20250522T170000&p1=224&p2=179&p3=136&p4=268&p5=367&p6=438&p7=248&p8=240) 7 | - View the [calendar][], or subscribe ([Google Calendar][], [ical file][]). 8 | - _Please Note:_ The date or time may change. Please check this agenda the 9 | week of the meeting to confirm. While we try to keep all calendars accurate, 10 | this agenda document is the source of truth. 11 | - **Video Conference Link**: https://zoom.us/j/93594710848 12 | - _Password:_ otel 13 | - **Live Notes**: [Live Notes][] 14 | 15 | [calendar]: https://calendar.google.com/calendar/embed?src=linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com 16 | [google calendar]: https://calendar.google.com/calendar?cid=bGludXhmb3VuZGF0aW9uLm9yZ19pazc5dDl1dWoycDMyaTNyMjAzZGd2NW1vOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t 17 | [ical file]: https://calendar.google.com/calendar/ical/linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com/public/basic.ics 18 | [live notes]: https://docs.google.com/document/d/1f8RdYS_avbBcH1AGa1wMGYxrGVS8_HKfMAB8gjQ8ZfE/edit?usp=sharing 19 | 20 | ## Attendees 21 | 22 | 23 | | Name | GitHub | Organization | Location | 24 | | :----------------- | :------------ | :----------------- | :-------------------- | 25 | | Pascal Senn (Host) | @pascalsenn | ChilliCream | Zurich, CH | 26 | | Trask Stalnaker | @trask | Microsoft | Portland, OR, US | 27 | | Eli Oshinsky | @eli0shin | PayPal | Baltimore, MD, US | 28 | | Bryn Cooke | @BrynCooke | Apollo | Norfolk, UK | 29 | | Benjie Gillam | @benjie | Graphile | Chandler's Ford, UK | 30 | 31 | 32 | ## Agenda 33 | 34 | 1. Agree to Membership Agreement, Participation & Contribution Guidelines and Code of Conduct (1m, Host) 35 | - [Specification Membership Agreement](https://github.com/graphql/foundation) 36 | - [Participation Guidelines](https://github.com/graphql/graphql-wg#participation-guidelines) 37 | - [Contribution Guide](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md) 38 | - [Code of Conduct](https://github.com/graphql/foundation/blob/master/CODE-OF-CONDUCT.md) 39 | - Meetings are [published to YouTube](https://www.youtube.com/@GraphQLFoundation/videos) and we may use LLM/AI summary tools 40 | 1. Introduction of attendees (5m, Host) 41 | 1. Determine volunteers for note taking (1m, Host) 42 | 1. Review agenda (2m, Host) 43 | 1. Check for [ready for review agenda items](https://github.com/graphql/otel-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Ready+for+review+%F0%9F%99%8C%22+sort%3Aupdated-desc) (5m, Host) 44 | 1. Define how we communicate asynchronsoly (5m, Host) 45 | 1. Discuss which Resource and Trace Attributes/Tags are relevant (15m, Host) 46 | -------------------------------------------------------------------------------- /agendas/2025/10-Oct/23-otel-wg-october-2025.md: -------------------------------------------------------------------------------- 1 | | This is an open meeting: To attend, edit and PR this file. (Edit: ✎ above, or press "e") | 2 | | ---------------------------------------------------------------------------------------- | 3 | 4 | # OTel WG — October 2025 5 | 6 | - **Date & Time**: [October 23, 2025, 10:00 – 11:00 AM PDT](https://www.timeanddate.com/worldclock/converter.html?iso=20251023T170000&p1=224&p2=179&p3=136&p4=268&p5=367&p6=438&p7=248&p8=240) 7 | - View the [calendar][], or subscribe ([Google Calendar][], [ical file][]). 8 | - _Please Note:_ The date or time may change. Please check this agenda the 9 | week of the meeting to confirm. While we try to keep all calendars accurate, 10 | this agenda document is the source of truth. 11 | - **Video Conference Link**: https://zoom.us/j/93594710848 12 | - _Password:_ otel 13 | - **Live Notes**: [Live Notes][] 14 | 15 | [calendar]: https://calendar.google.com/calendar/embed?src=linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com 16 | [google calendar]: https://calendar.google.com/calendar?cid=bGludXhmb3VuZGF0aW9uLm9yZ19pazc5dDl1dWoycDMyaTNyMjAzZGd2NW1vOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t 17 | [ical file]: https://calendar.google.com/calendar/ical/linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com/public/basic.ics 18 | [live notes]: https://docs.google.com/document/d/1f8RdYS_avbBcH1AGa1wMGYxrGVS8_HKfMAB8gjQ8ZfE/edit?usp=sharing 19 | 20 | ## Attendees 21 | 22 | 23 | | Name | GitHub | Organization | Location | 24 | | :----------------- | :------------ | :----------------- | :-------------------- | 25 | | Pascal Senn (Host) | @pascalsenn | ChilliCream | Zurich, CH | 26 | | Eli Oshinsky | @eli0shin | PayPal | Baltimore, MD | 27 | | Valentin Cocaud | @EmrysMyrddin | The Guild | Nantes, FR | 28 | | Marco Costa | @marcotc | Datadog | Victoria, BC, CA | 29 | 30 | ## Agenda 31 | 32 | 1. Agree to Membership Agreement, Participation & Contribution Guidelines and Code of Conduct (1m, Host) 33 | - [Specification Membership Agreement](https://github.com/graphql/foundation) 34 | - [Participation Guidelines](https://github.com/graphql/graphql-wg#participation-guidelines) 35 | - [Contribution Guide](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md) 36 | - [Code of Conduct](https://github.com/graphql/foundation/blob/master/CODE-OF-CONDUCT.md) 37 | - Meetings are [published to YouTube](https://www.youtube.com/@GraphQLFoundation/videos) and we may use LLM/AI summary tools 38 | 1. Introduction of attendees (5m, Host) 39 | 1. Determine volunteers for note taking (1m, Host) 40 | 1. Review agenda (2m, Host) 41 | 1. Check for [ready for review agenda items](https://github.com/graphql/otel-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Ready+for+review+%F0%9F%99%8C%22+sort%3Aupdated-desc) (5m, Host) 42 | 1. Reminder: [grants available for key initiatives](https://graphql.org/community/foundation/community-grant/) (1m, Host) 43 | 1. Continue discussions about errors (15m, Host) 44 | 1. Start discussion about meters (15m, Host) 45 | -------------------------------------------------------------------------------- /agendas/2025/06-Jun/26-otel-wg-june-2025.md: -------------------------------------------------------------------------------- 1 | | This is an open meeting: To attend, edit and PR this file. (Edit: ✎ above, or press "e") | 2 | | ---------------------------------------------------------------------------------------- | 3 | 4 | # OTel WG — June 2025 5 | 6 | - **Date & Time**: [June 26, 2025, 10:00 – 11:00 AM PDT](https://www.timeanddate.com/worldclock/converter.html?iso=20250626T170000&p1=224&p2=179&p3=136&p4=268&p5=367&p6=438&p7=248&p8=240) 7 | - View the [calendar][], or subscribe ([Google Calendar][], [ical file][]). 8 | - _Please Note:_ The date or time may change. Please check this agenda the 9 | week of the meeting to confirm. While we try to keep all calendars accurate, 10 | this agenda document is the source of truth. 11 | - **Video Conference Link**: https://zoom.us/j/93594710848 12 | - _Password:_ otel 13 | - **Live Notes**: [Live Notes][] 14 | 15 | [calendar]: https://calendar.google.com/calendar/embed?src=linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com 16 | [google calendar]: https://calendar.google.com/calendar?cid=bGludXhmb3VuZGF0aW9uLm9yZ19pazc5dDl1dWoycDMyaTNyMjAzZGd2NW1vOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t 17 | [ical file]: https://calendar.google.com/calendar/ical/linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com/public/basic.ics 18 | [live notes]: https://docs.google.com/document/d/1f8RdYS_avbBcH1AGa1wMGYxrGVS8_HKfMAB8gjQ8ZfE/edit?usp=sharing 19 | 20 | ## Attendees 21 | 22 | 23 | | Name | GitHub | Organization | Location | 24 | | :---------------- | :------------ | :----------------- | :-------------------- | 25 | | Pascal Senn (Host)| @pascalsenn | ChilliCream | Zurich, CH | 26 | | Bryn Cooke | @BrynCooke | Apollo | Norfolk, UK | 27 | | Valentin Cocaud | @EmrysMyrddin | The Guild | Nantes, FR | 28 | | Rob Van Gennip | @ravangen | Shopify | Toronto, CA | 29 | | Eli Oshinsky | @eli0shin | PayPal | Baltimore, MD | 30 | 31 | ## Agenda 32 | 33 | 1. Agree to Membership Agreement, Participation & Contribution Guidelines and Code of Conduct (1m, Host) 34 | - [Specification Membership Agreement](https://github.com/graphql/foundation) 35 | - [Participation Guidelines](https://github.com/graphql/graphql-wg#participation-guidelines) 36 | - [Contribution Guide](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md) 37 | - [Code of Conduct](https://github.com/graphql/foundation/blob/master/CODE-OF-CONDUCT.md) 38 | - Meetings are [published to YouTube](https://www.youtube.com/@GraphQLFoundation/videos) and we may use LLM/AI summary tools 39 | 1. Introduction of attendees (5m, Host) 40 | 1. Determine volunteers for note taking (1m, Host) 41 | 1. Review agenda (2m, Host) 42 | 1. Check for [ready for review agenda items](https://github.com/graphql/otel-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Ready+for+review+%F0%9F%99%8C%22+sort%3Aupdated-desc) (5m, Host) 43 | 1. Continue discussion on Tracing [(Attributes & Spans)](https://docs.google.com/spreadsheets/d/1vmBAil0hy3Os2ufRzyyiB4UXYVK6uIXK3r8jBptSsa0/edit?gid=0#gid=0) (15m, Pascal) 44 | -------------------------------------------------------------------------------- /agendas/2025/04-Apr/24-otel-wg-april-2025.md: -------------------------------------------------------------------------------- 1 | | This is an open meeting: To attend, edit and PR this file. (Edit: ✎ above, or press "e") | 2 | | ---------------------------------------------------------------------------------------- | 3 | 4 | # OTel WG — April 2025 5 | 6 | - **Date & Time**: [April 24, 2025, 10:00 – 11:00 AM PDT](https://www.timeanddate.com/worldclock/converter.html?iso=20250424T170000&p1=224&p2=179&p3=136&p4=268&p5=367&p6=438&p7=248&p8=240) 7 | - View the [calendar][], or subscribe ([Google Calendar][], [ical file][]). 8 | - _Please Note:_ The date or time may change. Please check this agenda the 9 | week of the meeting to confirm. While we try to keep all calendars accurate, 10 | this agenda document is the source of truth. 11 | - **Video Conference Link**: https://zoom.us/j/93594710848 12 | - _Password:_ otel 13 | - **Live Notes**: [Live Notes][] 14 | 15 | [calendar]: https://calendar.google.com/calendar/embed?src=linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com 16 | [google calendar]: https://calendar.google.com/calendar?cid=bGludXhmb3VuZGF0aW9uLm9yZ19pazc5dDl1dWoycDMyaTNyMjAzZGd2NW1vOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t 17 | [ical file]: https://calendar.google.com/calendar/ical/linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com/public/basic.ics 18 | [live notes]: https://docs.google.com/document/d/1f8RdYS_avbBcH1AGa1wMGYxrGVS8_HKfMAB8gjQ8ZfE/edit?usp=sharing 19 | 20 | ## Attendees 21 | 22 | 23 | | Name | GitHub | Organization | Location | 24 | | :------------------ | :------------ | :----------------- | :-------------------- | 25 | | Pascal Senn (Host) | @pascalsenn | ChilliCream | Zurich, CH | 26 | | Benjie Gillam | @benjie | Graphile | Chandler's Ford, UK | 27 | | Trask Stalnaker | @trask | Microsoft | Portland, OR, US | 28 | | Michael Staib | @michaelstaib | ChilliCream | Zurich, CH | 29 | | Valentin Cocaud | @EmrysMyrddin | The Guild | Nantes, FR | 30 | | Bryn Cooke | @BrynCooke | Apollo | Norfolk, UK | 31 | | Caroline Rodewig | @carodewig | Apollo | Traverse City, MI, US | 32 | 33 | ## Agenda 34 | 35 | 1. Agree to Membership Agreement, Participation & Contribution Guidelines and Code of Conduct (1m, Host) 36 | - [Specification Membership Agreement](https://github.com/graphql/foundation) 37 | - [Participation Guidelines](https://github.com/graphql/graphql-wg#participation-guidelines) 38 | - [Contribution Guide](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md) 39 | - [Code of Conduct](https://github.com/graphql/foundation/blob/master/CODE-OF-CONDUCT.md) 40 | - Meetings are [published to YouTube](https://www.youtube.com/@GraphQLFoundation/videos) and we may use LLM/AI summary tools 41 | 1. Introduction of attendees their motivation & goals (10m, Host) 42 | 1. Determine volunteers for note taking (1m, Host) 43 | 1. Review agenda (2m, Host) 44 | 1. Check for [ready for review agenda items](https://github.com/graphql/otel-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Ready+for+review+%F0%9F%99%8C%22+sort%3Aupdated-desc) (5m, Host) 45 | 1. Introduction and current state of OpenTelemetry in GraphQL (5m, Pascal) 46 | 1. Identify and collect core use cases we want to support (10m, Pascal) 47 | - Focus on what we want to discover or enable through OTEL data 48 | 1. Roadmap planning and goals (5m, Pascal) 49 | 1. Initial draft discussion (5m, Pascal) 50 | -------------------------------------------------------------------------------- /wg.config.js: -------------------------------------------------------------------------------- 1 | // @ts-check 2 | 3 | /** @type {import('wgutils').Config} */ 4 | const config = { 5 | name: "OTel WG", 6 | repoUrl: "https://github.com/graphql/otel-wg", 7 | videoConferenceDetails: `https://zoom.us/j/93594710848 8 | - _Password:_ otel`, 9 | liveNotesUrl: "https://docs.google.com/document/d/1f8RdYS_avbBcH1AGa1wMGYxrGVS8_HKfMAB8gjQ8ZfE/edit?usp=sharing", 10 | timezone: "US/Pacific", 11 | frequency: "monthly", 12 | // For "last" set nth to -1 13 | nth: 4, 14 | weekday: "Th", // M, Tu, W, Th, F, Sa, Su 15 | time: "10:00-11:00", // 24-hour clock, range 16 | attendeesTemplate: `\ 17 | | Name | GitHub | Organization | Location | 18 | | :--------------- | :------------ | :----------------- | :-------------------- | 19 | ` 20 | /* 21 | // Additional configuration (optional): 22 | 23 | agendasFolder: "agendas", 24 | dateAndTimeLocations: 'p1=224&p2=179&p3=136&p4=268&p5=367&p6=438&p7=248&p8=240', 25 | joiningAMeetingFile: "JoiningAMeeting.md", 26 | filenameFragment: "wg-primary", 27 | description: `\ 28 | The GraphQL Working Group meets regularly to discuss changes to the 29 | [GraphQL Specification][] and other core GraphQL projects. This is an open 30 | meeting in which anyone in the GraphQL community may attend. 31 | 32 | This is the primary monthly meeting, which typically meets on the first Thursday 33 | of the month. In the case we have additional agenda items or follow ups, we also 34 | hold additional secondary meetings later in the month.`, 35 | links: { 36 | "graphql specification": "https://github.com/graphql/graphql-spec", 37 | calendar: "https://calendar.google.com/calendar/embed?src=linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com", 38 | "google calendar": "https://calendar.google.com/calendar?cid=bGludXhmb3VuZGF0aW9uLm9yZ19pazc5dDl1dWoycDMyaTNyMjAzZGd2NW1vOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t", 39 | "ical file": "https://calendar.google.com/calendar/ical/linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com/public/basic.ics", 40 | }, 41 | secondaryMeetings: [ 42 | { 43 | // Wednesday, not Thursday 44 | dayOffset: -1, 45 | nth: 2, 46 | time: "16:00-17:00", 47 | name: "Secondary, APAC", 48 | // filenameFragment: "wg-secondary-apac", 49 | description: `\ 50 | The GraphQL Working Group meets regularly to discuss changes to the 51 | [GraphQL Specification][] and other core GraphQL projects. This is an open 52 | meeting in which anyone in the GraphQL community may attend. 53 | 54 | This is a secondary meeting, timed to be acceptable for those in Asia Pacific 55 | timezones, which typically meets on the second Wednesday of the month. The 56 | primary meeting is preferred for new agenda, where this meeting is for overflow 57 | agenda items, follow ups from the primary meeting, or agenda introduced by those 58 | who could not make the primary meeting time.`, 59 | }, 60 | { 61 | nth: 3, 62 | time: "10:30-12:00", 63 | name: "Secondary, EU", 64 | filenameFragment: "wg-secondary-eu", 65 | description: `\ 66 | The GraphQL Working Group meets regularly to discuss changes to the 67 | [GraphQL Specification][] and other core GraphQL projects. This is an open 68 | meeting in which anyone in the GraphQL community may attend. 69 | 70 | This is a secondary meeting, timed to be acceptable for those in European 71 | timezones, which typically meets on the third Thursday of the month. The 72 | primary meeting is preferred for new agenda, where this meeting is for overflow 73 | agenda items, follow ups from the primary meeting, or agenda introduced by those 74 | who could not make the primary meeting time.`, 75 | }, 76 | ], 77 | */ 78 | }; 79 | 80 | module.exports = config; 81 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # GraphQL OpenTelemetry Working Group 2 | 3 | This working group is a subcommittee of the 4 | [GraphQL Working Group](https://github.com/graphql/graphql-wg) with the 5 | following primary purpose: 6 | 7 | > Define the best practices and semantic conventions for using OpenTelemetry with GraphQL. 8 | 9 | Anyone in the public GraphQL community may attend a meeting of this 10 | subcommittee, provided they first sign the 11 | [Specification Membership Agreement](https://github.com/graphql/graphql-wg/tree/main/membership) 12 | or belong to an organization which has signed. 13 | 14 | This repository holds [agendas](./agendas) and [notes](./notes) for all meetings 15 | past and upcoming as well as [shared RFC documents](./rfcs). Anyone may edit an 16 | upcoming event's agenda to _attend_ or _propose an agenda item_. 17 | 18 | All meetings occur via video conference, however participating company offices 19 | are welcome to host guests. 20 | 21 | This is a short-running WG and meetings are typically scheduled ad-hoc. Check the 22 | [agendas](./agendas) for the exact date and time of upcoming meetings. 23 | 24 | Keep track of future upcoming meetings by subscribing to the 25 | [Google Calendar](https://calendar.google.com/calendar?cid=bGludXhmb3VuZGF0aW9uLm9yZ19pazc5dDl1dWoycDMyaTNyMjAzZGd2NW1vOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t) 26 | or 27 | [ical file](https://calendar.google.com/calendar/ical/linuxfoundation.org_ik79t9uuj2p32i3r203dgv5mo8%40group.calendar.google.com/public/basic.ics). 28 | (maintained in UTC because time zones are hard). 29 | 30 | ### Joining a meeting? 31 | 32 | To request participation in an upcoming meeting, please send a pull request by 33 | editing the relevant [meeting agenda](./agendas). 34 | 35 | ### Want to help us keep up? 36 | 37 | We're always looking for volunteers to help take notes from the meetings, the 38 | results of which are shared in [`notes/`](./notes). If you're interested in 39 | taking notes, sign up for a meeting in [`agendas/`](./agendas) and indicate that 40 | you're willing to be a note taker. 41 | 42 | ## Participation guidelines 43 | 44 | Meetings with many participants, especially over video, can easily get hard to 45 | follow or run off course. When we talk about issues we care about, it's easy to 46 | get into heated debate. In order to respect everyone's time, and arrive to 47 | worthwhile outcomes, this subcommittee follows the 48 | ["Participation guidelines" in the GraphQL Working Group](https://github.com/graphql/graphql-wg/blob/main/README.md#participation-guidelines); 49 | a summary of which is: 50 | 51 | - Participate 52 | - Don't talk too much 53 | - Volunteer to take notes 54 | - Have an outcome in mind 55 | - Contribute 56 | - Choose your battles 57 | - Champion alternatives 58 | - Block progress as a last resort 59 | - Be patient and persistent 60 | 61 | ## Contributing to this repo 62 | 63 | This repository is managed by EasyCLA. Project participants must sign the free 64 | ([GraphQL Specification Membership agreement](https://preview-spec-membership.graphql.org) 65 | before making a contribution. You only need to do this one time, and it can be 66 | signed by 67 | [individual contributors](http://individual-spec-membership.graphql.org/) or 68 | their [employers](http://corporate-spec-membership.graphql.org/). 69 | 70 | To initiate the signature process please open a PR against this repo. The 71 | EasyCLA bot will block the merge if we still need a membership agreement from 72 | you. 73 | 74 | You can find 75 | [detailed information here](https://github.com/graphql/graphql-wg/tree/main/membership). 76 | If you have issues, please email 77 | [operations@graphql.org](mailto:operations@graphql.org). 78 | 79 | ### Commit access 80 | 81 | Commit access is granted to this repo to members of the 82 | [GraphQL TSC](./GraphQL-TSC.md) and some regular attendees of subcommittee 83 | meetings. To request commit access, please reach out to a TSC member. 84 | 85 | ## Generating agendas 86 | 87 | To create the agenda files for a given month YYYY/MM, run the following command: 88 | 89 | ``` 90 | yarn && yarn gen-agenda YYYY MM 91 | ``` 92 | -------------------------------------------------------------------------------- /notes/2025/summary-2025-05-22.md: -------------------------------------------------------------------------------- 1 | # Meeting Summary for OTel WG 2 | 3 | **NOTICE**: This summary was auto-generated by Zoom's "AI". AI-generated 4 | content may be inaccurate or misleading. Always check for accuracy. If in 5 | doubt, please consult the meeting recording at 6 | https://youtube.com/@GraphQLFoundation/playlists 7 | 8 | - Meeting start: 2025-05-22T17:00:23Z 9 | - Meeting end: 2025-05-22T18:02:25Z 10 | - Summary start: 2025-05-22T17:01:23Z 11 | - Summary end: 2025-05-22T18:02:15Z 12 | 13 | The team held their second meeting about OpenTelemetry work for GraphQL, focusing on establishing communication channels and documenting tracing and metrics attributes. They discussed tracing conventions for GraphQL operations and agreed to maintain separate spans for HTTP and GraphQL operations, while also addressing concerns about variable batching and operation naming. The group explored various span attributes and naming conventions, considering both internal and public GraphQL APIs, and concluded with plans to create issues for future discussions on meeting frequency and conventions. 14 | 15 | ## Next Steps 16 | 17 | - Pascal to open a GitHub issue for voting on the next meeting time and frequency. 18 | - Pascal to enable discussions on the GitHub repository. 19 | - Trask to add the topic of using operation names in span names to the next week's semantic convention general meeting for guidance. 20 | - All participants to continue the discussion on span naming conventions and cardinality concerns asynchronously on GitHub. 21 | - All participants to review and refine the proposed attributes for GraphQL tracing, including operation name, operation type, and operation hash. 22 | - All participants to consider the different use cases for public vs. internal GraphQL APIs when defining tracing conventions. 23 | 24 | ## Summary 25 | 26 | ### OpenTelemetry GraphQL Tracing Discussion 27 | 28 | The group held their second meeting about OpenTelemetry work for GraphQL, with Pascal leading the discussion. They agreed to use GitHub for asynchronous communication, with Trask monitoring the repository for notifications. The main focus was on tracing and metrics attributes, which will be documented in a Google sheet shared by Pascal. The team discussed the need for consistent semantic conventions in the GraphQL ecosystem, with Eli highlighting challenges around observability of GraphQL systems. They agreed to start with GitHub discussions and issues before considering additional communication methods if needed. 29 | 30 | ### GraphQL Span Tracing Conventions 31 | 32 | The team discussed tracing conventions for GraphQL operations, focusing on how to handle server operation spans and HTTP spans. They agreed to maintain separate spans for HTTP and GraphQL operations rather than combining them, as Eli and Bryn explained this approach avoids noise in observability tools and works well with most APMs. The team identified variable batching as an area requiring further discussion, particularly regarding whether it should create one operation span per batch or multiple spans per batch item. They decided to continue the discussion asynchronously through GitHub pull requests once the initial document is finalized. 33 | 34 | ### Operation Name Requirements and Constraints 35 | 36 | The team discussed the attributes for operations, focusing on the requirement levels for operation names in spans and metrics. They agreed that operation names should be conditionally required for spans due to potential cardinality issues, while for metrics, it could be recommended or opt-in depending on the system's scale. Trask raised concerns about user-controlled operation names potentially leading to overflow in metric systems, similar to a previous CVE issue with HTTP method names. The team considered limiting operation names to a predefined list of common method names to address these concerns. 37 | 38 | ### GraphQL Span Attributes Discussion 39 | 40 | The team discussed GraphQL span attributes, focusing on operation name, type, hash, and ID. They agreed that operation name can be empty but should be conditionally required, while operation type will be lowercase and required. The team debated hash representation, with Benjie suggesting a prefix format like "sha256:" to allow for future algorithm changes. Trask explained that operation ID would be conditionally required if document ID is provided, and Eli inquired about standard fields to differentiate between different types of work, which Trask confirmed has been discussed but no final decision was made. 41 | 42 | ### GraphQL Span Naming Challenges 43 | 44 | The group discusses the challenges of naming spans in GraphQL tracing, particularly balancing usefulness with potential cardinality issues. They consider using operation names, which is common practice but susceptible to attacks in public APIs. The discussion touches on different approaches for internal vs. public GraphQL APIs. Trask suggests adding this topic to the next semantic convention meeting for further guidance. The group also debates the merits of fixed span names versus dynamic ones. They agree to create an issue to vote on changing the meeting frequency to bi-weekly and potentially adjusting the meeting time. 45 | -------------------------------------------------------------------------------- /notes/2025/summary-2025-04-24.md: -------------------------------------------------------------------------------- 1 | # Meeting Summary for OTel WG 2 | 3 | **NOTICE**: This summary was auto-generated by Zoom's "AI". AI-generated 4 | content may be inaccurate or misleading. Always check for accuracy. If in 5 | doubt, please consult the meeting recording at 6 | https://youtube.com/@GraphQLFoundation/playlists 7 | 8 | - Meeting start: 2025-04-24T16:59:26Z 9 | - Meeting end: 2025-04-24T18:03:22Z 10 | - Summary start: 2025-04-24T16:59:54Z 11 | - Summary end: 2025-04-24T18:02:36Z 12 | 13 | The group discussed the need for standardized OpenTelemetry conventions for GraphQL, focusing on defining useful traces and metrics without including overly large payloads. They explored challenges related to managing large amounts of data in APIs and GraphQL, as well as handling GraphQL errors in OpenTelemetry spans. The group agreed to meet monthly and use the OpenTelemetry working group repository for follow-up discussions and issues. 14 | 15 | ## Next Steps 16 | 17 | - Trask to write up different options for handling GraphQL errors in spans and follow up with the group. 18 | - All participants to research and write up topics discussed in the meeting asynchronously before the next meeting. 19 | - Pascal to create a new agenda entry for the next monthly meeting. 20 | - All participants to add topics to the new agenda for the next meeting. 21 | - All participants to open and follow issues in the OTel WG repository for further discussion. 22 | 23 | ## Summary 24 | 25 | ### Standardizing OpenTelemetry for GraphQL Conventions 26 | 27 | The group discusses the goals and motivations for creating standardized OpenTelemetry conventions for GraphQL. Pascal from ChilliCream emphasizes the need for common spans, tags, and meters across different GraphQL implementations to enable plug-and-play functionality with various monitoring tools. Benjie aims to ensure the conventions are sensible and don't introduce performance issues. Trask from OpenTelemetry offers support to help make this effort successful. Bryn from Apollo highlights the challenges of connecting to third-party APMs without standardized conventions. The group agrees on the importance of defining useful traces and metrics that don't include overly large payloads like full GraphQL documents. 28 | 29 | ### Monitoring Operations and Resolver Performance 30 | 31 | Pascal discussed the need for a tool to monitor the performance of operations and resolvers over time, including error tracking and data loader performance. He also mentioned the importance of understanding client and versioning semantics. Bryn raised concerns about the high cardinality of field-level metrics and their potential impact on API performance. Pascal explained their approach to tracing asynchronous resolvers and field requests, but acknowledged the need to consider the upper boundary of meter dimensions. Trask suggested that the default limit in open telemetry SDKs is 2,000 combinations. 32 | 33 | ### API Data Management Challenges Discussed 34 | 35 | Pascal and Bryn discussed the challenges of managing large amounts of data, particularly in the context of APIs and GraphQL. Pascal suggested that the issue might be similar for both REST and GraphQL APIs. Benjie proposed a potential solution, suggesting that the expense of loading object records and lists of object records could be reduced. Bryn proposed starting with easier tasks, such as moving documents from recommended to optional, and suggested that this could be a less controversial approach. 36 | 37 | ### Version Tracking in Client-Server Interactions 38 | 39 | In the meeting, Benjie and Pascal discussed the importance of identifying and tracking different versions of a document, particularly in the context of client and server interactions. They agreed that a unique identifier, such as a SHA hash, could be used to distinguish between versions. Pascal suggested that this information could be correlated with user agent data to identify specific client versions. However, they also acknowledged that this might not be necessary for all systems, especially those with hot reloading capabilities. The team also discussed the potential for proxying GraphQL to multiple places and the need for version tracking in gateway scenarios. Valentin proposed using a version attribute that could be represented in different ways, such as a hash or a specific ID, depending on the system being used. 40 | 41 | ### Schema Hash for Interoperability Discussion 42 | 43 | Bryn, Valentin, Pascal, Trask, and Benjie discussed the use of schema hash and its potential for interoperability. Pascal suggested defining resource attributes in the semantic convention, which could include an optional schema ID. Trask agreed but noted that some edge cases might require further consideration. Pascal also raised the issue of schema changes during runtime in federated scenarios, which could affect the service version. Trask suggested starting with a span attribute and potentially moving it to an entity attribute as the entities work develops. The team agreed to pick one approach for now. 44 | 45 | ### GraphQL Error Handling in OpenTelemetry 46 | 47 | The group discusses how to handle GraphQL errors in OpenTelemetry spans. They explore options for reporting errors, including using span attributes, events, and logs. Trask agrees to write up different options for handling errors. The group also discusses the importance of capturing schema coordinates and operation paths for GraphQL errors. They decide to meet monthly and use the OpenTelemetry working group repository for follow-up issues and discussions. 48 | -------------------------------------------------------------------------------- /notes/2025/summary-2025-10-23.md: -------------------------------------------------------------------------------- 1 | # Meeting Summary for OTel WG 2 | 3 | **NOTICE**: This summary was auto-generated by Zoom's "AI". AI-generated 4 | content may be inaccurate or misleading. Always check for accuracy. If in 5 | doubt, please consult the meeting recording at 6 | https://youtube.com/@GraphQLFoundation/playlists 7 | 8 | - Meeting start: 2025-10-23T17:01:21Z 9 | - Meeting end: 2025-10-23T18:07:00Z 10 | - Summary start: 2025-10-23T17:04:06Z 11 | - Summary end: 2025-10-23T18:06:59Z 12 | 13 | The team discussed error handling conventions and reviewed pull requests for the main repository, with Pascal proposing a new approach for handling errors that includes using exceptions for non-graphical errors and a custom structure for graphical errors. They explored challenges around schema coordinates and error tracking in GraphQL, particularly focusing on security concerns and implementation complexities, while also discussing metrics and monitoring for GraphQL applications. The conversation ended with plans to review existing meters, explore prior art in other languages and ecosystems, and reconvene in January, with Pascal agreeing to add schema coordinates to the specification. 14 | 15 | ## Next Steps 16 | 17 | - Valentin: Sign the contributor agreement 18 | - Pascal: Reach out to Trask to invite him to join the January meeting 19 | - Marco: Reach out to Trask as backup in case Pascal forgets 20 | - Pascal or team: Open an issue and tag Trask on GitHub 21 | - Pascal: Talk to Benjie about adding schema coordinates to error reporting 22 | - Pascal: Add schema coordinate field to the error specification pull request 23 | - Pascal: Add schema version/signature identifier to the specification for correlating traces with schema versions 24 | - All participants: Read through existing meters in HTTP and other ecosystems before the January meeting to inform GraphQL meter discussion 25 | - Pascal: Add parsing duration, validation duration, and variable coercion duration meters to the discussion document for January meeting 26 | 27 | ## Summary 28 | 29 | ### Year-End Meeting Agenda Review 30 | 31 | The meeting began with Pascal noting that the next meeting would be the last one for the year due to upcoming holidays. Valentin and Marco joined, and Pascal introduced the agenda, which included merging pull requests and reviewing attendees' agreements. Valentin mentioned using his personal email for commits, and Pascal clarified that using The Guild email would ensure acceptance. The meeting's guidelines were reviewed, including the publication of meetings on YouTube and the creation of LLM and AR summaries. Pascal encouraged attendees to volunteer for note-taking, and the conversation ended with a plan to review pull requests and introduce attendees. 32 | 33 | ### Error Handling Proposal Discussion 34 | 35 | The team discussed error handling conventions and a pending pull request for the main repository. Pascal explained his proposal for handling errors, which includes using exceptions for non-graphical errors and a custom structure for graphical errors with properties like error message, location, and extensions code. They agreed to reach out to Trask from Microsoft for input on the proposal before the next meeting in January. Pascal emphasized the importance of supporting both event and log event formats for error reporting, as it would make it easier to collect telemetry data from customers. 36 | 37 | ### GraphQL Error Handling Implementation 38 | 39 | Marco and Pascal discussed the implementation of GraphQL error handling, focusing on how to structure error data in OpenTelemetry. They agreed to use a JSON map for error attributes, which allows for more flexibility while maintaining compatibility with existing querying systems. Valentin mentioned a related project on Hive Console that aims to track error rates across schema coordinates, which could help identify problematic areas in the system. 40 | 41 | ### Schema Path Security Discussion 42 | 43 | Valentin and Pascal discussed the challenges of gathering paths corresponding to specific fields in a schema and the potential security implications of exposing schema coordinates through error messages. They agreed that while exposing type names might not be a significant security risk, it's important to consider the broader implications of error messages. Pascal suggested that error coordinates could be useful for correlation, but noted that this might not always be feasible due to performance issues in JavaScript. Valentin mentioned a potential workaround using UTs to fake sync paths, but acknowledged that there's no perfect solution for this problem yet. 44 | 45 | ### GraphQL Schema Security and Tracing 46 | 47 | The team discussed challenges with schema coordinates and error tracking in GraphQL, particularly around security concerns and implementation complexities. They agreed to add schema coordinates to tracing without exposing them to clients, and Pascal will add this to the specification. The group also explored ways to identify schema versions, with Pascal and Valentin noting that a stable identifier is needed, though the exact implementation remains unclear. Finally, they discussed metrics in GraphQL, with Pascal explaining that due to the single endpoint and arbitrary queries, meaningful metering is limited, and they currently only have one useful metric: tracking active operations. 48 | 49 | ### GraphQL Metrics and Monitoring Discussion 50 | 51 | The team discussed metrics and monitoring for GraphQL applications, focusing on how to handle high cardinality and visualize data effectively. Pascal and Marco explored the benefits and limitations of different approaches, including using root fields instead of individual queries or mutations. They agreed that better schema design could reduce the need for root field metrics, but acknowledged that mutations and complex queries still present challenges. The group decided to review existing meters and explore prior art in other languages and ecosystems before reconvening in January. They also briefly discussed the importance of exemplars for tracing and debugging in GraphQL applications. 52 | -------------------------------------------------------------------------------- /notes/2025/2025-04-24.md: -------------------------------------------------------------------------------- 1 | # GraphQL OTel WG Notes - April 2025 2 | 3 | **Watch the replays:** 4 | [GraphQL OTel Working Group Meetings on YouTube](https://www.youtube.com/playlist?list=PLP1igyLx8foFO2xFpWp7IturLnInoyWv1) 5 | 6 | Agenda: 7 | [https://github.com/graphql/otel-wg/blob/main/agendas/2025/04-Apr/24-otel-wg-april-2025.md](https://github.com/graphql/otel-wg/blob/main/agendas/2025/04-Apr/24-otel-wg-april-2025.md) 8 | 9 | ## Introduction of attendees their motivation & goals (10m, Host) 10 | 11 | - Pascal: Want to make a standard that everyone can follow so it can be consumed 12 | by all types of tooling. 13 | - Benjie: Want to ensure we're not over-recording so we don't shoot ourselves in 14 | the foot by e.g. recording every resolver call. 15 | - Trask: OpenTelemetry community can't do all libraries so we want 16 | libraries/specs to be empowered to do that work themselves. Want to help you 17 | be successful and be a model for future efforts. 18 | - Bryn: third party APMs, hard to get started due to lack of OTel standard for 19 | GraphQL. GraphQL Document is rather heavy to send! 20 | 21 | ## Determine volunteers for note taking (1m, Host) 22 | 23 | - Benjie 24 | 25 | ## Review agenda (2m, Host) 26 | 27 | - Review what's out there. 28 | - Define what we want to achieve - what insights do users need? 29 | - How do we get there? 30 | 31 | ## Introduction and current state of OpenTelemetry in GraphQL (5m, Pascal) 32 | 33 | - Current graphql registry in OTel website lists operation type / operation name 34 | / document are the only standard attributes right now 35 | - And sending the document for every operation is not ideal - they can get 36 | large! Waste of bandwidth/storage. 37 | - [https://github.com/open-telemetry/semantic-conventions/pull/562](https://github.com/open-telemetry/semantic-conventions/pull/562) 38 | specifies traces, but would be nice to add meters/counters too. 39 | 40 | ## Identify and collect core use cases we want to support (10m, Pascal) 41 | 42 | - Focus on what we want to discover or enable through OTEL data 43 | - Versioning: which client versions are in use. 44 | - How long to validate, coerce, compile, plan, execute the operation? Cache hit 45 | / cache miss? 46 | - Bryn: must work nicely with the rest of the OTel specs - e.g. can we get any 47 | of this from HTTP semantic conventions? 48 | - How does cardinality come into this? Field-level metrics will have a high 49 | cardinality. 50 | - Pascal: GraphQL.js OTel wrapping of resolvers makes sync execution suddenly 51 | really expensive 52 | - Pascal: HotChocolate only traces asynchronous resolvers, no need for sync 53 | - Chillicream have a meter that counts how many times a field was requested. 54 | Attribute differentiates the field requested. Static allocation of 55 | meter/counter, increment it by one when a request comes in - 50 counters for 56 | 50 fields. 57 | - More pressure on API doesn't produce more metrics, helps avoid memory 58 | increases. 59 | - Trask: default cap in OTel is 2000 combinations (it is adjustable). 60 | - Bryn: combination of field against type is the unique identifier ("schema 61 | coordinates") - you may end up with 10k of these. 62 | - Costs in DataDog/etc are usually based on cardinality. 63 | - HTTP has route which has placeholders for ID/etc - so you'd have similar 64 | issues with a REST API. 65 | - Route is recommended, e.g. generated by SpringBoot controller paths. 66 | - Benjie: if we ruled out scalar fields, there'd be a lot less cardinality 67 | - Bryn: Operation name and query type belong in there. 68 | - Benjie: hash of the document (e.g. persisted query/trusted document ID) 69 | - Trask: User_Agent.original is enabled by default (not under HTTP.) 70 | - Pascal: version of the schema 71 | - Benjie: recommend this is an arbitrary string 72 | - Pascal: probably a resource attribute rather than a regular one 73 | - Valentin: hot loading of the schema 74 | - Pascal: for gateway a combination of a hash of the schema and the version of 75 | the server would work 76 | - Trask (chat): `service.version` 77 | - Trask: you can define resource conventions alongside the semantic conventions 78 | - Trask: is it immutable and singleton? 79 | - immutable: cannot change during the runtime of the service currently; but 80 | "entities" work is addressing these issues around immutability and 81 | organization. Defines descriptive attributes that can or cannot change. 82 | - Pascal: `service.version` is likely the deployed Docker version or git 83 | version, but for federation the schema may change at runtime so since resource 84 | attributes are immutable we'll need a span attribute 85 | - Valentin (chat): It can happen in rare cases that some spans with 2 different 86 | schema id are interleaved 87 | - Bryn: errors are key. HTTP allows for HTTP status. 88 | - Trask: `error.type` and `error.message` may be appropriate 89 | - Could have a GraphQL-specific error map 90 | - Span events are being transitioned to log-based events. 91 | - Each error could be recorded as an event. 92 | - Span events are being deprecated. 93 | 94 | # Use Cases 95 | ## Attributes of traces 96 | - operatrion name 97 | - operation type 98 | - operation hash 99 | - client type/name/version -> user_agent.orginal 100 | - schema id/version <- user configurable *optional* 101 | - span.status 102 | 103 | ## Errors 104 | error.type 105 | error.message 106 | - schema coordinate 107 | - path 108 | 109 | ## Performance Insights 110 | - How does an operation performe over time 111 | - How does a resolver perform over time 112 | - Which operations/fields/resolver have errors 113 | - How big are dataloader batches 114 | - How many operations are executed/executing -> subscription 115 | - Which client & version sent a request? What is there distribution? 116 | - How long does an operation take to validate, coerce (& compile) 117 | 118 | ## Error Insights 119 | - What are the most common errors 120 | 121 | ## Schema Evolution Questions 122 | - Is this field in use? 123 | - How often is a field requested? 124 | - How many requests are made including a field? 125 | 126 | ## Distributed GraphQL 127 | - Query Plan Step? 128 | - Query Planning Duration? 129 | 130 | -------------------------------------------------------------------------------- /notes/2025/summary-2025-09-25.md: -------------------------------------------------------------------------------- 1 | # Meeting Summary for OTel WG 2 | 3 | **NOTICE**: This summary was auto-generated by Zoom's "AI". AI-generated 4 | content may be inaccurate or misleading. Always check for accuracy. If in 5 | doubt, please consult the meeting recording at 6 | https://youtube.com/@GraphQLFoundation/playlists 7 | 8 | - Meeting start: 2025-09-25T17:03:03Z 9 | - Meeting end: 2025-09-25T18:05:26Z 10 | - Summary start: 2025-09-25T17:03:52Z 11 | - Summary end: 2025-09-25T18:03:03Z 12 | 13 | The team discussed error handling approaches for graphical operations and spans, including the use of semantic conventions and OpenTelemetry for recording exceptions and events. They explored the trade-offs between using GraphQL for data synchronization versus simpler methods, while also discussing the challenges of cursor-based pagination and performance monitoring. The group addressed the handling of errors in distributed tracing systems, focusing on how to record and categorize errors on root spans while maintaining scalability and useful UI feedback. 14 | 15 | ## Next Steps 16 | 17 | - Pascal to push a new pull request with error definitions for GraphQL in OpenTelemetry. 18 | - Team to decide on the error type attribute for GraphQL errors . 19 | - Team to propose using span events for reporting GraphQL errors with attributes like error.message, error.location, error.path, and optional error.extensions.code. 20 | - Team to discuss subscription and deferred queries for traces in a future meeting after completing the error specifications. 21 | 22 | ## Summary 23 | 24 | ### Error Handling and Observability Discussion 25 | 26 | Pascal and Rob discussed the need to consult with Trask regarding the direction for error handling, as they have two options: using semantic conventions for errors or developing their own conventions for graphical errors involving complex objects. Pascal inquired about Rob's current use of aggregations and metrics, noting that Rob's team uses Prometheus for self-hosted observability, which avoids issues with pricing and data processing. They also discussed the scale of Rob's team and company, highlighting the cost-effectiveness of self-hosting Prometheus compared to using services like Datadog. 27 | 28 | ### GraphQL Challenges in API Management 29 | 30 | Rob and Pascal discussed the challenges and considerations of using GraphQL for data synchronization and public API management. They explored the overlap between performance monitoring in observability tools and GraphQL usage, noting that Shopify's public API serves both merchants and developers. Pascal raised concerns about the overhead of using GraphQL for data synchronization, suggesting that simpler methods like JSON streaming might be more efficient. They also touched on the trend of making internal APIs public and the unique use cases of Shopify's API, including data synchronization and app ecosystem development. 31 | 32 | ### Data Fetching and Error Handling 33 | 34 | The group discussed challenges with data fetching and cursor-based pagination, noting that it's harder to jump to arbitrary points in time compared to previous offset pagination methods. Pascal and Rob reviewed semantic conventions for errors, particularly focusing on how to record exceptions and events in OpenTelemetry. They discussed the transition from using span events to log records, and the need to map GraphQL errors into events that would work across all backends, though this approach lacks stack traces and types compared to exceptions. 35 | 36 | ### Error Handling in Spans Discussion 37 | 38 | Pascal, Rob, and Valentin discussed error handling in spans and its implications for UI feedback. They debated whether spans should be flagged as errors for all top-level errors or only for significant issues. Pascal suggested appending errors as events on spans while keeping spans as successful, but Rob argued that this could mask problems. They agreed that authentication and authorization errors should always flag spans as errors, but were less certain about validation and other types of errors. The group acknowledged the need to balance providing useful error information without overwhelming the UI with red indicators. 39 | 40 | ### Distributed Tracing Exception Handling 41 | 42 | Pascal and Rob discussed the handling of exceptions and errors in a distributed tracing system. They agreed that exceptions should be aggregated and handled separately from regular errors, with a focus on stack trace hashing to group similar exceptions. Rob suggested the need for a way to link spans with error information in a reporting system, while Pascal explained that unhandled exceptions would automatically be recorded in spans. They discussed the possibility of using custom specifications for GraphQL errors and agreed that errors and exceptions could coexist for the same issue, with errors being visible to users and exceptions representing unhandled issues. 43 | 44 | ### GraphQL Error Reporting with OpenTelemetry 45 | 46 | The team discussed how to handle error reporting in GraphQL operations using OpenTelemetry. They agreed to record errors on the root span for simplicity and scalability, rather than trying to correlate them with specific resolver spans. They decided to use the error extension code as a recommended way to categorize errors. Pascal and Rob discussed the trade-offs between recording detailed error information versus keeping traces simple and scalable. The team also considered the needs of dashboard developers who prefer to see most information on the root span. They plan to propose these ideas to the OTEL team for feedback. 47 | 48 | ### Graphical Operations Error Handling Discussion 49 | 50 | Pascal and Rob discussed the handling of errors in graphical operations and spans. They agreed that errors should be marked as such in spans, even if they are partial successes, as this helps identify issues. Rob expressed concern about exceptions being treated as errors, but Pascal clarified that the status of spans, not attributes, determines if a span is marked as an error. They decided to use span events to report errors, with attributes like arrow.message.error, error.location, and error.path, and proposed making error.extensions.code optional. 51 | 52 | ### API Tracing and Error Handling 53 | 54 | The team discussed API tracing and error handling, with Pascal noting that timestamp precision might not be crucial. They agreed to focus on completing error definitions in the next few meetings before addressing metrics, while Valentin raised questions about handling subscriptions and long-lived spans. Pascal mentioned a previous discussion with Quay about deferred elements and proposed creating separate spans to track deferred operations, though he expressed uncertainty about the optimal approach for subscription tracing. 55 | -------------------------------------------------------------------------------- /notes/2025/summary-2025-08-28.md: -------------------------------------------------------------------------------- 1 | # Meeting Summary for OTel WG 2 | 3 | **NOTICE**: This summary was auto-generated by Zoom's "AI". AI-generated 4 | content may be inaccurate or misleading. Always check for accuracy. If in 5 | doubt, please consult the meeting recording at 6 | https://youtube.com/@GraphQLFoundation/playlists 7 | 8 | - Meeting start: 2025-08-28T17:00:14Z 9 | - Meeting end: 2025-08-28T18:11:25Z 10 | - Summary start: 2025-08-28T17:01:14Z 11 | - Summary end: 2025-08-28T18:07:07Z 12 | 13 | The meeting focused on discussing observability and tracing specifications for GraphQL applications, with the team exploring various technical aspects including error handling, operation IDs, and data loader behavior. The team worked on refining terminology and naming conventions for spans, attributes, and operations, while also addressing concerns about security and cardinality in persisted queries. Updates were shared on ongoing pull requests and future workgroup meetings, with plans to discuss GraphQL errors and distributed graphical work in upcoming sessions. 14 | 15 | ## Next Steps 16 | 17 | - Pascal: Reach out to Trask via email about handling GraphQL errors and the new logging format in OpenTelemetry. 18 | - Pascal: Work with the team on updating the specification for the new format that uses logging instead of events on traces in OpenTelemetry. 19 | - Pascal: Verify with Benjie and Michael the correct terminology from the GraphQL spec regarding "request" vs "operation" terminology. 20 | - Pascal: Rephrase the documentation about operation domains with bounded cardinality to emphasize that persisted operations are recommended for public APIs and clarify security implications. 21 | - Pascal: Update the specification to explicitly mention trusted documents/persisted operations and clarify that automatic persisted queries don't provide the same security benefits. 22 | - Pascal: Review the naming of "GraphQL operation ID" versus potentially renaming it to better reflect its relationship with persisted operations. 23 | - Pascal: Keep the pull requests open for further discussion on terminology. 24 | - Pascal: Review and potentially remove the GraphQL operation name attribute from the parsing span. 25 | - Marco: Clarify his comment about "request" terminology in the pull request. 26 | - Team: Finalize the format options for GraphQL selection path representation. 27 | 28 | ## Summary 29 | 30 | ### GraphQL Observability Collaboration Discussion 31 | 32 | The meeting began with introductions, where Brian explained his role in the Spring Team, focusing on Spring for GraphQL, and his interest in collaborating on observability instrumentation for Java-based GraphQL applications. Marco introduced himself as working on Datadog, emphasizing his interest in contributing to OTel semantics. Pascal outlined the agenda and mentioned that the current work on observability for GraphQL would be discussed further, with a focus on error handling. Pascal also noted plans to reach out to Trask for additional insights on error handling conventions. 33 | 34 | ### GraphQL Tracing Specifications Review 35 | 36 | The team discussed GraphQL tracing specifications and PR reviews, focusing on attributes and formats. They agreed to use JSON path for selection paths due to its advantages for querying in telemetry systems and familiarity in testing contexts. Pascal explained that persisted operations are primarily a security feature, hashing queries in development to secure production environments. The team also confirmed that the GraphQL operation ID field should be named simply "ID" as per the HTTP specification. 37 | 38 | ### GraphQL Operations Terminology Clarification 39 | 40 | The team discussed terminology around GraphQL operations, with Pascal explaining that while "server" might be questionable, "client" makes more sense for operations that don't necessarily run on servers. Marco clarified that in the GraphQL specification, "request" refers to the entire process including type checking, while "operation" refers to execution. The team also discussed persisted queries, with Pascal warning that automated persisted queries don't provide security benefits and should be avoided, while Brian emphasized that API owners need to maintain control over query cardinality regardless of whether they use persisted queries. 41 | 42 | ### Refining Trusted Document Language 43 | 44 | Pascal, Brian, and Marco discussed refining the language around trusted documents and persisted operations, emphasizing the need for explicit phrasing and clarity, especially regarding bounded cardinality and automatic persisted queries. Pascal explained the addition of attributes to spans for better observability, highlighting their utility for querying spans based on attribute values. They also discussed harmonizing telemetry data across different backends and agreed on the necessity of certain attributes like operation names and IDs for unique identification. Marco raised a point about the correctness of using graphical operation names during parsing, which Pascal confirmed was acceptable due to attribute cardinality considerations. 45 | 46 | ### GraphQL Document ID Terminology Clarification 47 | 48 | The team discussed the terminology and usage of document IDs in GraphQL operations, particularly focusing on the distinction between the ID of a persisted document and the ID passed in a POST request. Brian and Pascal clarified that while the latter is often referred to as the "operation ID," there might be confusion due to the generic use of "ID" across specifications. Pascal suggested the need to verify the correct terminology and potentially rename attributes for clarity, while Brian found a relevant RFC that could help resolve the confusion. The team agreed to further research the correct naming conventions and ensure alignment in their documentation. 49 | 50 | ### Span Naming Conventions for Tracing 51 | 52 | Pascal and the team discussed the structure and naming conventions for spans in their tracing system. They agreed to use low cardinality tags for span names, such as "graph call data loader batch" and "data loader name," to facilitate easy discovery of executed operations. Pascal suggested adding batch size information to spans for monitoring purposes, though Rob raised concerns about potential cardinality issues with unique values. The team decided to address metrics and histogram representations in a future phase, as logs are not effective for GraphQL tracing. 53 | 54 | ### GraphQL Data Loader Behavior Discussion 55 | 56 | Eli and Pascal discussed the behavior of data loaders in GraphQL, focusing on batch sizes and caching mechanisms. They clarified that the data loader batch size refers to the number of IDs passed to a database query, not the number of concurrent requests. Pascal explained that data loaders cache results for a single request to avoid N+1 queries and ensure consistent data across a resolver tree. Marco inquired about caching across requests, and Pascal confirmed that while data loaders can serve cached values within a request, serving cached values across requests is a different pattern not typically implemented with data loaders. 57 | 58 | ### Graphical Work Updates and Planning 59 | 60 | Pascal presented updates on a pull request for distributed graphical work, which includes two spans: graphical server operation planning and operation step execution. He explained that these concepts could be useful beyond federation, potentially benefiting projects like GraphFast. Brian agreed to discuss the ideas with the GraphQL Java team. The group also discussed upcoming workgroup meetings, with Pascal mentioning a talk about their workgroup's goals in two weeks. Eli expressed interest in discussing GraphQL errors at the next meeting, and Pascal agreed to follow up with Trask about potential input on this topic. 61 | -------------------------------------------------------------------------------- /notes/2025/summary-2025-06-26.md: -------------------------------------------------------------------------------- 1 | # Meeting Summary for OTel WG 2 | 3 | **NOTICE**: This summary was auto-generated by Zoom's "AI". AI-generated 4 | content may be inaccurate or misleading. Always check for accuracy. If in 5 | doubt, please consult the meeting recording at 6 | https://youtube.com/@GraphQLFoundation/playlists 7 | 8 | - Meeting start: 2025-06-26T17:00:26Z 9 | - Meeting end: 2025-06-26T18:06:08Z 10 | - Summary start: 2025-06-26T17:01:56Z 11 | - Summary end: 2025-06-26T18:03:50Z 12 | 13 | The meeting focused on discussing GraphQL tracing and semantic conventions, with participants reviewing specifications and guidelines while working on an Excel document from a previous session. The team explored various aspects of span implementation, including error handling, document validation tracking, and resolver tracing, while considering performance implications and best practices for different use cases. The discussion concluded with agreement to continue work on span definitions and resolver tracing configurations, with participants encouraged to think about desired metadata and potential span names for future meetings. 14 | 15 | ## Next Steps 16 | 17 | - All attendees to think about what metadata should be added to a resolver trace and what the span name of a resolver trace should be. 18 | - Pascal to add more description and examples to the document regarding the discussed span types (validation, parsing, variable coercion). 19 | - Pascal to continue the discussion on resolver tracing and how to solve related challenges in the next meeting. 20 | - Trask to follow up on the progress of the errors and exceptions discussion in the Open Telemetry specification, planned for July. 21 | - All attendees to consider the use case of having more than just an operation span in GraphQL tracing. 22 | - Pascal to sync with Benjie regarding the logical placement of validation and variable coercion spans in relation to the operation execution span. 23 | - All attendees to consider the potential value of adding a data loader trace to the Open Telemetry semantic conventions for GraphQL. 24 | 25 | ## Summary 26 | 27 | ### GraphQL Community Meeting: Guidelines Review 28 | 29 | The meeting began with introductions from Pascal, Rob, Eli, and Trask, who are members of a community focused on GraphQL and open-source contributions. Pascal noted that only half of the expected attendees had signed up and mentioned that the meeting would be recorded and published on YouTube. The group discussed the agenda, which included reviewing the spec membership agreement, participation guidelines, and contribution guidelines, as well as a code of conduct. The main focus of the meeting was to continue work on an Excel document started in a previous session, with Rob joining for the first time. 30 | 31 | ### Semantic Span Attributes Discussion 32 | 33 | Pascal and Valentin discussed defining span attributes and their cardinality for semantic conventions, focusing on four previously defined attributes and considering additional spans like the operation span. Trask mentioned progress on supporting complex attributes for spans, which would enable capturing multiple errors as a list, and indicated that the broader discussion on errors and exceptions would resume in July. Pascal suggested postponing the error discussion once more to align with the updated timeline. 34 | 35 | ### JSON Encoding and Telemetry Handling 36 | 37 | The team discussed encoding JSON objects with key-value pairs and lists, and explored the possibility of reusing the official error handling method by adding a new attribute. They debated the inclusion of metadata in operation spans for mutations, queries, and subscriptions, with a focus on lifecycle events like lexing, parsing, and stack validation. Pascal raised questions about how to handle caching and document parsing in telemetry, noting that some implementations compile object structures once and reuse them. Trask was asked about prior art in other implementations, and the team considered whether OpenTelemetry semantic conventions addressed similar use cases. 38 | 39 | ### GraphQL Document Validation Tracking 40 | 41 | The team discussed the implementation of document validation tracking in GraphQL, focusing on whether to use spans or metrics. Pascal and Eli agreed that while validation only occurs once per document, tracking it could provide valuable insights for tooling and analysis. Trask suggested exploring the possibility of using attributes on spans to record validation times, while Pascal noted concerns about cardinality explosion with metrics. The discussion concluded with Trask offering to consult the Semantic Convention group about potential alternatives to nested spans for this use case. 42 | 43 | ### OpenTelemetry GraphQL Span Implementation 44 | 45 | The team discussed the implementation of spans in OpenTelemetry for GraphQL operations. Pascal and Eli debated the logical sequence of spans, with Eli suggesting that the operation span should wrap all GraphQL-related activities to maintain semantic clarity. Rob warned about the challenge of adding metadata to operation spans before document parsing. Pascal agreed to provide examples to illustrate the differences in span implementation approaches. 46 | 47 | ### GraphQL Span Implementation Discussion 48 | 49 | The team discussed the value and implementation of different spans in GraphQL tracing, focusing on operation execution, validation, and resolver tracing. They agreed that separate spans for validation and execution could be valuable for tooling, error correlation, and understanding execution patterns, though the level of detail should remain optional to accommodate different use cases. Pascal proposed adding parsing as a separate span due to its distinct characteristics from validation, while noting that some implementation-specific spans like context building and authentication might not be universally applicable. The team decided to continue the discussion in the next work group meeting to finalize the span definitions and ensure they capture all relevant GraphQL execution phases. 50 | 51 | ### GraphQL Resolver Tracing Best Practices 52 | 53 | The group discussed resolver tracing in GraphQL servers, with Pascal warning about the performance impact of tracing all fields and emphasizing the need for careful configuration. Eli shared that PayPal traces only the first 2 levels of important resolvers, while Rob explained Shopify's use of OpenTelemetry Ruby with sampled verbosity, noting they may be tracing too much. The discussion concluded with agreement that data loaders should be addressed after resolving resolver tracing, and Pascal emphasized the importance of proper span naming and the need to make resolver tracing opt-in by default. 54 | 55 | ### Challenges in Nested Object Tracing 56 | 57 | The team discussed the challenges of tracing nested objects and fields in graphical requests, where Trask explained that most semantic conventions focus on network calls rather than internal spans. Trask clarified that while Java instrumentation allows for method-level tracing, they typically disable internal spans by default to avoid noise, offering them as an opt-in feature. Pascal inquired about profiling capabilities, and Trask described OpenTelemetry's sample-based profiling, which correlates profiling data with traces, though he expressed skepticism about the value of capturing 150 nested spans in production. 58 | 59 | ### GraphQL Tracing Challenges Discussion 60 | 61 | The group discussed challenges with GraphQL resolver tracing and distributed tracing in server environments. Pascal emphasized the need for a GraphQL server resolver trace with specific attributes, while Rob and Eli highlighted the trade-offs between granular tracing and performance, suggesting that tracing should focus on major data fetching operations rather than every resolver call. The team agreed to continue the discussion at the next meeting, with participants encouraged to think about desired metadata for resolver traces and potential span names. Valentin noted that resolver tracing might not be relevant for distributed federated gateways, but distributed tracing for subrequests remains valuable. 62 | -------------------------------------------------------------------------------- /notes/2025/summary-2025-07-24.md: -------------------------------------------------------------------------------- 1 | # Meeting Summary for OTel WG 2 | 3 | **NOTICE**: This summary was auto-generated by Zoom's "AI". AI-generated 4 | content may be inaccurate or misleading. Always check for accuracy. If in 5 | doubt, please consult the meeting recording at 6 | https://youtube.com/@GraphQLFoundation/playlists 7 | 8 | - Meeting start: 2025-07-24T17:00:36Z 9 | - Meeting end: 2025-07-24T18:14:55Z 10 | - Summary start: 2025-07-24T17:01:34Z 11 | - Summary end: 2025-07-24T18:12:29Z 12 | 13 | The meeting introduced participants to a work group focused on improving GraphQL observability, with discussions centered around tracing implementation, span naming conventions, and error handling in OpenTelemetry. The team explored various technical approaches including resolver tracking, path formatting, and error reporting mechanisms, while considering how to align with community practices and maintain compatibility across different telemetry tools. Pascal announced plans to prepare a draft specification for GraphQL telemetry and transition documentation to a semantic conventions repository, with the team agreeing to continue discussions through GitHub pull requests. 14 | 15 | ## Next Steps 16 | 17 | - Team: Define span naming conventions for GraphQL resolver traces 18 | - Team: Determine how to handle resolver traces for public GraphQL APIs 19 | - Team: Consider different execution models when defining tracing specifications 20 | - Team: Specify how to trace root fields vs internal resolvers for performance monitoring 21 | - Team: Define attributes for distinguishing between mutation and query resolver traces 22 | - Team: Consider how to handle batching across different root fields in tracing specifications 23 | - Team: Discuss tracing specifications for GraphQL execution steps in future meetings 24 | - Team: Remove "is deprecated" attribute from the official specification 25 | - Team: Consider removing return type as an attribute 26 | - Team: Evaluate if "field.is deprecated" attribute should be extended to include information about deprecated arguments and types 27 | - Team: Review and potentially adjust the naming convention for resolver traces 28 | - Team: Consider how to handle asynchronous work in resolver traces 29 | - Pascal: Consult with Michael and Benjie about path formatting conventions in the GraphQL community 30 | - Pascal: Check if there are established practices for path formatting in GraphQL implementations 31 | - Pascal: Update the specification regarding path formatting options 32 | - Pascal: Evaluate if custom attributes like "lazy" or "asynchronous" should be included in the specification 33 | - Pascal: Create draft specification document from Excel content and make pull request to Semantic Conventions repository 34 | - Pascal: Prepare presentation for GraphQLConf work group about telemetry problems 35 | - Team: Continue discussions about error tracking and propagation in next meeting with Trask 36 | - Team: Review and provide feedback on pull request once it's made to Semantic Conventions repository 37 | 38 | ## Summary 39 | 40 | ### GraphQL Observability Work Group Introduction 41 | 42 | The meeting introduced participants to a work group focused on improving GraphQL observability, with Pascal hosting and explaining the purpose of their ongoing discussions. Attendees included Marco from Data Dog, Eli from PayPal, and Rob from Shopify, who shared their backgrounds and interests in GraphQL and observability. Pascal mentioned that the meeting would be published on YouTube and that they might use AI tools to generate meeting notes. The group discussed transitioning from a spreadsheet format to a draft specification format as they prepare for an upcoming conference, with Pascal emphasizing the need to move the project forward. 43 | 44 | ### GraphQL Tracing Span Naming 45 | 46 | The team discussed GraphQL tracing implementation, focusing on span naming conventions and resolver tracing. Pascal explained that they will have a root GraphQL server operation trace with potential sub-traces for parsing, validation, variable coercion, and execution. The team debated how to name resolver spans, with Eli suggesting using descriptive names like "graphql.server.operation" or "server.resolver.field" while Marco raised questions about naming conventions and cardinality issues. They agreed to consult with Trask from the hotel funding team about resolver span naming conventions. 47 | 48 | ### GraphQL API Security and Telemetry 49 | 50 | Eli and Pascal discussed the cardinality of span names in GraphQL server resolver traces, noting that while root traces are typically aggregated into time series, resolver traces have more flexibility. They explored how to mitigate potential vulnerabilities in HTTP URL paths and operation names, with Eli highlighting the importance of using matched paths from routers and discussing persistent queries as a defense mechanism. Pascal suggested that most GraphQL APIs should be private and use persistent operations, as this approach aligns with the needs of known clients and enhances the functionality of telemetry systems. 51 | 52 | ### GraphQL Execution Tracking Strategies 53 | 54 | The group discussed different approaches to tracking entry points and execution in GraphQL systems, with Rob explaining their use of attribute-based data and root fields to manage resolver invocations and reduce instrumentation overhead. Pascal and Rob explored the differences between traditional GraphQL execution and GraphFast models, particularly around execution steps and federated architectures, while Marco raised questions about batching across root fields and the need for different levels of metrics (operation, root field, and resolver) for monitoring and dashboarding. The discussion concluded with Pascal suggesting that mutations deserve separate tracking from queries due to their sequential nature and transactional behavior, while queries can be treated more uniformly. 55 | 56 | ### GraphQL Resolver Tracing Implementation 57 | 58 | The team discussed the implementation of resolver tracing in GraphQL, focusing on how to identify and attribute different resolver types and execution paths. Pascal explained the concept of coordinates for tracing, which can be used to uniquely identify resolvers across the schema. The group agreed that while all resolver executions could be traced, it's important to configure tracing levels based on system needs, with some implementations tracing everything while others focus on I/O operations. They also discussed the naming conventions for resolver traces, considering whether to include arguments and directives, and decided to propose "GraphQL Server Resolver Execution" as a potential name with explicit mention of whether arguments are included. 59 | 60 | ### GraphQL Type Naming Conventions Discussion 61 | 62 | The team discussed terminology and naming conventions for GraphQL types and paths in OpenTelemetry. They debated whether to use "parent type" or "declaring type" and agreed that the return type could be removed as it's redundant with schema information. Rob suggested using a JSON array format for paths, which Pascal explained could be technically possible but might not be well-supported in all telemetry tools. The team also discussed the limitations of tracking deprecated fields and agreed that more schema-based information would be needed for comprehensive deprecation tracking. 63 | 64 | ### Implementation Formatting and Specification Discussion 65 | 66 | The team discussed formatting options for implementations, with Pascal suggesting they should align with community practices and Marco advocating for a format with slashes for easier regex matching. They agreed to keep both path and alias information in the specification, with Pascal emphasizing their value for correlation and filtering. The group also considered adding attributes for lazy/async operations and error tracking, though they decided to defer further discussion on error handling to the next meeting. 67 | 68 | ### GraphQL Error Tracking in Spans 69 | 70 | The team discussed how to handle errors in GraphQL spans for OpenTelemetry tracing. Pascal explained that spans are automatically marked as errors when resolvers fail to return a value, and there's no need to add additional failure markers. Eli emphasized the need to track errors across resolver operations, even when data is returned, to understand failure rates and error propagation. The team identified a challenge in tracking errors without null propagation, and agreed to further discuss how to annotate spans with error information in future meetings. 71 | 72 | ### OpenTelemetry GraphQL Specification Planning 73 | 74 | The team discussed progress on resolver specifications and error reporting in OpenTelemetry. Pascal announced plans to prepare a draft specification for GraphQL telemetry and move existing documentation to the semantic conventions repository, where it will be available for implementation. The team agreed to continue discussions through GitHub pull requests rather than email threads, with Pascal committing to create and share a draft document within the next few weeks. 75 | --------------------------------------------------------------------------------