✨ [RUM-13680] Add support for GraphQL GET requests with query params (APQ)

[rgaignault]

Motivation

When using Apollo's Automatic Persisted Queries (APQ) with useGETForHashedQueries: true, GraphQL requests are sent as GET instead of POST. In this case, operationName, variables, and query are passed as URL query params instead of request body.

The extractGraphQlRequestMetadata function only inspects the request body, so it misses GraphQL metadata for GET requests in this particular context. As it was requested by a customer we could support it by parsing the url.

Changes

We could support it by parsing the url.

FR:#4063

Test instructions

Checklist

• Tested locally
• Tested on staging
• Added unit tests for this change.
• Added e2e/integration tests for this change.
• Updated documentation and/or relevant AGENTS.md file

[cit-pr-commenter-54b7da]

Bundles Sizes Evolution

📦 Bundle Name	Base Size	Local Size	𝚫	𝚫%	Status
Rum	167.88 KiB	168.25 KiB	+375 B	+0.22%	✅
Rum Profiler	4.33 KiB	4.33 KiB	0 B	0.00%	✅
Rum Recorder	24.48 KiB	24.48 KiB	0 B	0.00%	✅
Logs	56.26 KiB	56.26 KiB	0 B	0.00%	✅
Flagging	944 B	944 B	0 B	0.00%	✅
Rum Slim	124.86 KiB	125.22 KiB	+368 B	+0.29%	✅
Worker	23.63 KiB	23.63 KiB	0 B	0.00%	✅

🚀 CPU Performance

Action Name	Base CPU Time (ms)	Local CPU Time (ms)	𝚫%
RUM - add global context	0.0046	0.0051	+10.87%
RUM - add action	0.0126	0.0149	+18.25%
RUM - add error	0.0134	0.017	+26.87%
RUM - add timing	0.0027	0.0033	+22.22%
RUM - start view	0.003	0.0031	+3.33%
RUM - start/stop session replay recording	0.0007	0.0008	+14.29%
Logs - log message	0.014	0.0166	+18.57%

🧠 Memory Performance

Action Name	Base Memory Consumption	Local Memory Consumption	𝚫
RUM - add global context	26.01 KiB	28.65 KiB	+2.64 KiB
RUM - add action	49.35 KiB	52.55 KiB	+3.20 KiB
RUM - add timing	27.02 KiB	26.85 KiB	-174 B
RUM - add error	54.36 KiB	56.69 KiB	+2.33 KiB
RUM - start/stop session replay recording	26.51 KiB	27.36 KiB	+861 B
RUM - start view	423.18 KiB	430.81 KiB	+7.63 KiB
Logs - log message	45.20 KiB	49.89 KiB	+4.69 KiB

🔗 RealWorld

[bcaudan]

💬 suggestion: ‏what about passing directly the full request to this method? instead of passing every needed request attributes

[bcaudan]

💬 suggestion: ‏Instead of having the extract methods that call the build method internally, we could:

• rename the build method as sanitize since it seems to be the intent
• call the sanitize method from extractGraphQlRequestMetadata , so the specific extract methods would be more focused and the higher level method would manage the execution flow
• move the parseVariableParams to the sanitize function as well

[datadog-official]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage
• Patch Coverage: 69.57%
• Overall Coverage: 77.31% (-0.02%)

View detailed report

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 243664a | Docs | Datadog PR Page | Was this helpful? Give us feedback!}

[BenoitZugmeyer]

suggestion: do we need to validate this? Maybe we can just trust that it is correctly encoded?

If we still want this validation, I suggest to:

• move it to extractFromUrlQueryParams, since it's only useful in this case
• maybe introduce a tryJsonParse helper, because we already have a few usages in this file. Ex:

function tryJsonParse<T = unknown>(text: string): T | undefined {
  try { return JSON.parse(text) } catch {}
}

Then

  let graphqlBody: {
    query?: string
    operationName?: string
    variables?: unknown
  }

  try {
    graphqlBody = JSON.parse(requestBody)
  } catch {
    // Not valid JSON
    return
  }

  if (!graphqlBody) {
    return
  }

// becomes

  const graphqlBody = tryJsonParse<{
    query?: string
    operationName?: string
    variables?: unknown
  }>(requestBody)

  if (!graphqlBody) {
    return
  }