If you use the GitHub GraphQL API for team notification dashboards, audit-log exports, or any kind of organization compliance reporting, you have nine days when this lands. On July 1, 2026, GitHub deletes two fields from the Team type and the fields from seventeen audit-log entry types.
The fields are listed in GitHub's own breaking changes log:
-
Team.viewerSubscription— removed. Reason: "Team notifications subscriptions are being deprecated." -
Team.viewerCanSubscribe— removed. Same reason. - All scalar fields on
TeamAddMemberAuditEntry,TeamAddRepositoryAuditEntry,TeamChangeParentTeamAuditEntry,TeamRemoveMemberAuditEntry,TeamRemoveRepositoryAuditEntry, and twelve sibling repository/audit entry types — removed. Reason: "The GraphQL audit-log is deprecated. Please use the REST API instead."
The loud failure mode is the one most teams plan around. A query that selects a field GraphQL no longer recognizes fails server-side validation. You get a clear error, you regenerate types, you redeploy.
That's not the failure mode this article is about.
The failure mode worth thinking about is GraphQL's partial-error semantics — specifically, what happens to clients that don't treat the errors array as fatal.
What "removed" actually returns
When GitHub removes Team.viewerSubscription, queries that select it don't fail with a 4xx HTTP status. The HTTP layer returns 200 OK with a body like:
{
"data": {
"organization": {
"team": {
"name": "platform",
"viewerSubscription": null
}
}
},
"errors": [
{
"message": "Field 'viewerSubscription' doesn't exist on type 'Team'",
"locations": [{ "line": 5, "column": 9 }],
"path": ["organization", "team", "viewerSubscription"]
}
]
}
The exact shape depends on whether GitHub leaves the field validation-rejected (no data for the team at all) or treats it as a removed-but-tolerated field returning null. In practice, large-vendor GraphQL APIs deliberately bias toward the second shape during deprecation periods so that clients with partially-stale schemas don't go fully dark.
Either way, the client side of this is where it gets quietly bad.
1. The Apollo / urql / Relay "log and continue" pattern
Most production GraphQL client setups have an error link or middleware that logs errors[] to a telemetry sink and continues. The reasoning is sound — partial responses are useful, and a network-level failure should not be confused with a single-field schema mismatch.
The result is that a compliance dashboard that does:
const { data } = await client.query({ query: GET_TEAM_SUBS });
const subscribed = data.organization.team.viewerSubscription === 'SUBSCRIBED';
…silently flips subscribed to false on July 1. The Apollo error link logged the schema error to Sentry, where it joins the existing six hundred GraphQL errors nobody triages.
If the dashboard's job is to show "who on the platform team is muted on PR notifications," the dashboard reports "everybody is muted." If the job is to enforce "all leads must be subscribed to security-channel notifications," every lead's subscription check returns false and either the enforcement skips them (if the rule is "alert when subscribed == false") or alerts on everybody (if the rule is "alert when subscribed != true"). Most enforcement rules are written the second way, which means July 1 produces a wall of false-positive alerts and a tendency to mute the rule.
2. Persisted queries and codegen don't help
The standard answer to GraphQL drift — codegen with graphql-codegen or Relay's compiler, against an up-to-date schema — only helps if you're regenerating before July 1. The codegen does not know that a field that exists in your local schema today will be gone on a future date.
The deeper problem is persisted queries. A persisted-query setup hashes the query at build time and submits the hash at runtime. Server-side, GitHub validates against its live schema. The build that shipped last quarter persisted a query selecting Team.viewerSubscription. The build doesn't change between now and July 1. On July 1, the hashed query starts returning the partial-error shape above, and the client app never sees a code change to prompt regeneration.
If you have a persisted-query setup pointed at GitHub's GraphQL endpoint, every persisted hash that references the removed fields needs to be rebuilt and republished before July 1 — not after a deploy, after July 1.
3. The audit-log surface is a different problem
GitHub is not just removing two Team fields. It is deprecating the entire GraphQL audit-log subsystem and pointing users at the REST endpoint instead.
The seventeen entry types that get gutted on July 1 cover the common team and repository administrative actions:
-
TeamAddMemberAuditEntry,TeamRemoveMemberAuditEntry -
TeamAddRepositoryAuditEntry,TeamRemoveRepositoryAuditEntry TeamChangeParentTeamAuditEntry- The repository-side equivalents for visibility, archive, transfer, and access changes
A typical security pipeline does something like:
query Audit($org: String!, $cursor: String) {
organization(login: $org) {
auditLog(first: 100, after: $cursor) {
edges {
node {
__typename
... on TeamAddMemberAuditEntry {
createdAt
actorLogin
team { name }
user { login }
}
}
}
pageInfo { endCursor, hasNextPage }
}
}
}
After July 1, the node still has __typename, but every field inside the ... on TeamAddMemberAuditEntry fragment returns null or schema-errors out. The pipeline still iterates pages, still increments its "events processed" counter, still writes rows to the warehouse. The warehouse rows are tombstones — typename and timestamps if you're lucky, nothing if you're not.
The REST migration is non-trivial. The REST audit-log API uses cursor pagination via a phrase= query parameter rather than GraphQL connection cursors, returns flattened event objects rather than nested team { } / user { } shapes, and has different field names (actor vs actorLogin, team as a string vs an object). It's a rewrite, not a remap.
4. The Insights/Analytics integrations don't surface this
The third-party analytics tools layered on top of GitHub's GraphQL API — lowdefy, Sourcegraph batch changes that read audit data, GitHub-Actions-based compliance bots — typically use the GitHub Apps OAuth flow and inherit GraphQL access. None of them publish a "we use these fields" manifest. The only way to know whether one of them will break is to query its error logs after July 1, or to read its source.
The default posture is to assume any integration that touches Teams or audit data is affected unless its changelog explicitly says otherwise. The vendors with a published changelog (Octokit, gh CLI) will have already shipped a fix. The bespoke "we wrote a small dashboard for our compliance team" surface is where the drift lands.
How to find what's affected before July 1
Three commands worth running this week.
Grep your queries: grep -rE 'viewerSubscription|viewerCanSubscribe|TeamAddMemberAuditEntry|TeamRemoveMemberAuditEntry|TeamAddRepositoryAuditEntry|TeamRemoveRepositoryAuditEntry|TeamChangeParentTeamAuditEntry' src/ queries/ catches direct references. Add the twelve other audit-entry types if your reporting covers repository visibility/transfer changes. GitHub's breaking-changes page has the full list.
Inventory persisted queries: any GraphQL setup using Apollo's Automatic Persisted Queries or Relay's --persist-output flag has a JSON map of query hashes to query bodies. grep that map for the field names. The hashes themselves are content-addressed, so a hash referencing viewerSubscription won't change until the query body changes.
Replay last week's audit-log queries with the deprecation banner: GitHub returns an X-GitHub-Media-Type header and includes deprecation warnings in the errors[] array for fields scheduled for removal. If your client logs GraphQL errors anywhere — Sentry, Datadog, CloudWatch — filter for the message "Team notifications subscriptions are being deprecated" or "The GraphQL audit-log is deprecated" over the past 30 days. Anything that fires today will silently fail on July 1.
The published deprecation table is here: GitHub GraphQL API Breaking changes. The REST replacement for the audit log is documented under REST API endpoints for audit log.
The pattern this lands in is the one GraphQL APIs hit most often during big deprecation cycles. The schema validator doesn't care about wall-clock dates — until July 1, the field exists and queries succeed. On July 1, the field returns null with a partial error that most production clients are configured to swallow. The dashboards stop showing data, the compliance enforcers stop enforcing, and the alarms don't fire because the request never failed.
FlareCanary watches the response shapes of API endpoints you depend on and tells you when a field that used to be present starts coming back null. GraphQL partial-error responses are exactly the kind of drift that survives an Apollo error link and lands in a dashboard tile that's quietly wrong. flarecanary.com
