Merging to release-5.14.0: [TT-17578] Bump graphql-go-tools to fix Federation subscription-then-query null regression (#8345)#8362
Conversation
…query null regression (#8345) ## Description Bumps `github.com/TykTechnologies/graphql-go-tools` to pick up **TykTechnologies/graphql-go-tools#447**. ### The bug On a GraphQL Federation supergraph API, running a subscription (websocket) first and then a query over the same connection makes the query return `null` instead of data. Gateway logs show `websocket upgrade for GraphQL engine failed: 'upgrade' token not found in 'Connection' header` against the subgraphs. Regression introduced in 5.8.15 / 5.13.1 / 5.14.0 (clean on 5.8.14 and 5.13.0). ### Root cause The gateway tags an inbound websocket subscription request with a context value `GraphQLIsWebSocketUpgrade=true`. The library change in #446 ([TT-17442]) wrapped the subscription executor's context in a `mergedContext` that resolved values from that original request context, so the flag leaked into every subgraph fetch. The subgraphs then tried to perform a websocket handshake on plain HTTP fetches, which failed → `null`. ### The fix (library #447) The executor now builds its execution context without inheriting the original request's context values, while still forwarding the per-request header modifier — preserving TT-17442's per-user connection/credential isolation. See #447 for details and tests. ## Scope - Bumps the **v1** module only (`v1.6.2-0.20260610093432-c7048b604e16` → `v1.6.2-0.20260623130956-98d2c88fce43`). - The gateway's `graphql-go-tools/v2` pin predates TT-17442, so the v3/v2 engine path is **not** affected and is intentionally left unchanged. ## Verification - `go mod verify` passes; `internal/graphengine` and `apidef/adapter/...` build against the new pin. > Draft — depends on graphql-go-tools#447, which is not merged yet. The version pin points at the #447 branch commit and must be re-pinned to the squash-merge commit once #447 lands. [TT-17442]: https://tyktech.atlassian.net/browse/TT-17442?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ (cherry picked from commit 63316b3)
|
SentinelOne CNS Hardcoded Secret Detector SentinelOne CNS is a cloud-agnostic, agentless CSPM & CWPP solution that continuously detects and prevents vulnerabilities that have the highest probability of being exploited in Azure, AWS, Google Cloud, and Kubernetes. |
🚨 Jira Linter FailedCommit: The Jira linter failed to validate your PR. Please check the error details below: 🔍 Click to view error detailsNext Steps
This comment will be automatically deleted once the linter passes. |
|
This PR bumps the The root cause was a context flag ( The updated dependency contains a fix that isolates the execution context for each operation, preventing this flag from being inherited by subsequent queries. Files Changed AnalysisThe changes are confined to dependency management files:
This indicates the change is a dependency bump with no direct modifications to the gateway's source code. Architecture & Impact Assessment
Bug and Fix FlowThe following diagrams illustrate the behavior before and after the fix. Before (Incorrect Flow): sequenceDiagram
participant Client
participant Gateway
participant Subgraph
Client->>+Gateway: 1. GraphQL Subscription (WebSocket Upgrade)
Note over Gateway: Request context is tagged with<br/>`GraphQLIsWebSocketUpgrade=true`
Gateway-->>-Client: (Subscription established)
Client->>+Gateway: 2. GraphQL Query (over same connection)
Note over Gateway: Leaked context is used for query execution.
Gateway->>+Subgraph: 3. HTTP Fetch (with upgrade context)
Note over Subgraph: Expects WebSocket upgrade, but gets plain HTTP.
Subgraph-->>-Gateway: 4. Fails
Gateway-->>-Client: 5. Returns `null`
After (Corrected Flow): sequenceDiagram
participant Client
participant Gateway
participant Subgraph
Client->>+Gateway: 1. GraphQL Subscription (WebSocket Upgrade)
Gateway-->>-Client: (Subscription established)
Client->>+Gateway: 2. GraphQL Query (over same connection)
Note over Gateway: A new, clean execution context is created.<br/>The upgrade flag is not present.
Gateway->>+Subgraph: 3. Plain HTTP Fetch
Subgraph-->>-Gateway: 4. Returns data successfully
Gateway-->>-Client: 5. Returns query data
Scope Discovery & Context Expansion
Metadata
Powered by Visor from Probelabs Last updated: 2026-06-24T18:51:30.239Z | Triggered by: pr_opened | Commit: f663ca4 💡 TIP: You can chat with Visor using |
🎯 Recommended Merge TargetsBased on JIRA ticket TT-17578: Starting a subscription on a Federation API breaks subsequent queries Fix Version: Tyk 5.8.15Required:
📋 Workflow
|
✅ Security Check PassedNo security issues found – changes LGTM. ✅ Architecture Check PassedNo architecture issues found – changes LGTM. ✅ Performance Check PassedNo performance issues found – changes LGTM. Powered by Visor from Probelabs Last updated: 2026-06-24T18:51:26.621Z | Triggered by: pr_opened | Commit: f663ca4 💡 TIP: You can chat with Visor using |
|



TT-17578 Bump graphql-go-tools to fix Federation subscription-then-query null regression (#8345)
Description
Bumps
github.com/TykTechnologies/graphql-go-toolsto pick upTykTechnologies/graphql-go-tools#447.
The bug
On a GraphQL Federation supergraph API, running a subscription
(websocket) first and then a query over the same connection makes the
query return
nullinstead of data. Gateway logs showwebsocket upgrade for GraphQL engine failed: 'upgrade' token not found in 'Connection' headeragainst the subgraphs. Regression introduced in5.8.15 / 5.13.1 / 5.14.0 (clean on 5.8.14 and 5.13.0).
Root cause
The gateway tags an inbound websocket subscription request with a
context value
GraphQLIsWebSocketUpgrade=true. The library change in#446 (TT-17442) wrapped the subscription executor's context in a
mergedContextthat resolved values from that original request context,so the flag leaked into every subgraph fetch. The subgraphs then tried
to perform a websocket handshake on plain HTTP fetches, which failed →
null.The fix (library #447)
The executor now builds its execution context without inheriting the
original request's context values, while still forwarding the
per-request header modifier — preserving TT-17442's per-user
connection/credential isolation. See #447 for details and tests.
Scope
v1.6.2-0.20260610093432-c7048b604e16→v1.6.2-0.20260623130956-98d2c88fce43).graphql-go-tools/v2pin predates TT-17442, so thev3/v2 engine path is not affected and is intentionally left
unchanged.
Verification
go mod verifypasses;internal/graphengineandapidef/adapter/...build against the new pin.