Use POST for eTag caching GraphQL

What does this MR do and why?

GraphQL queries use a GET request for eTag caching to allow the browser to do a lot of the heavy lifting. This causes issues for customers who self-host and have strict limits from providers like AWS WAF where if a query string is too long the request will not complete. This MR moves eTag caching over to POST requests and builds a util function to do what the browser did for us with GET requests.

Locations

Currently eTag caching with GraphQL is used for 5 routes that can be seen here lib/gitlab/etag_caching/router/graphql.rb

Screenshots or screen recordings

Before After

How to set up and validate locally

  1. Enable feature flag

    etag_caching_post_requests
  2. Open the project's Build > Pipelines page, then open DevTools > Network and filter on graphql.

    • Look for: a POST to /api/graphql with no query string. The Payload tab shows operationName: getPipelines. Request headers include x-gitlab-graphql-resource-etag: /api/graphql:project_pipelines/<id>. The response is 200 with an etag header, and the request has no if-none-match.
  3. Wait about 60 seconds for the next poll, without changing anything.

    • Look for: the request sends if-none-match equal to the previous etag. The response is 304 with x-gitlab-from-cache: true and a very low x-runtime (tens of ms). The pipeline list stays on screen with no "An error occurred while loading pipelines".
  4. Start or retry a pipeline, then wait for the next poll.

    • Look for: the request sends the old if-none-match. The response is 200 with a new etag, no x-gitlab-from-cache, and a higher x-runtime. The list updates.
  5. Wait for another poll once the pipeline stops changing.

    • Look for: the request sends the latest etag, and the response is 304 with x-gitlab-from-cache: true again.
  6. Switch to another tab (for example Finished) or go to the next page of results.

    • Look for: the first request for that tab or page has no if-none-match, because each set of variables gets its own cache entry.
  7. Open a pipeline's details page.

    • Look for: the same POST and 304 pattern on requests with x-gitlab-graphql-resource-etag: /api/graphql:pipelines/id/<id>.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #618236

Edited by Payton Burdette

Merge request reports

Loading
Loading