>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3598935. --> Reported by: [pfrenssen](https://www.drupal.org/user/382067) Related to !80 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>This is part 1 of splitting the large contribution in <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/graphql_webform/-/work_items/3595219" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/graphql_webform/-/work_items/3595219</a></span> into reviewable pieces. It is the <strong>foundation</strong> the per-element issues build on, and should land first.</p> <p>When the module resolves a built form's elements, it walks the render array produced by Webform and exposes each element's metadata, default value and options. Two correctness problems exist in 3.x today:</p> <ul> <li><strong>Cacheability is dropped.</strong> Element render arrays carry cache metadata (cache tags, contexts, and a max-age) &mdash; for example a default value computed from a token like <code>[current-user:mail]</code> is per-user and must not be cached across users, and option lists built from entities carry the entities' cache tags. The current resolvers read values out of the render array but never bubble its <code>#cache</code> metadata into the GraphQL response, so the response is over-cached and can leak one user's data to another.</li> <li><strong>Non-renderable and placeholder elements are exposed.</strong> Elements that Webform decides not to render on the form (access-denied, <code>#access = FALSE</code>, value/markup-only containers in some cases) are still walked and surface as meaningless entries. Related to this, an unavailable form (see <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/graphql_webform/-/work_items/3595219" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/graphql_webform/-/work_items/3595219</a></span>'s <code>WebformForm</code> work) can still produce stray element entries.</li> </ul> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <ol> <li>Add a textfield whose <code>#default_value</code> is <code>[current-user:mail]</code>.</li> <li>Query the form's <code>elements { ... defaultValue }</code> as user A, then as user B.</li> <li><strong>Expected:</strong> each user sees their own e-mail; the response is not cached across users (a <code>user</code> cache context is present).<br><br> <strong>Actual:</strong> the token-derived default value is cached and the second user can be served the first user's value; the per-user cache context is missing from the response.</li> </ol> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Make the element resolvers <strong>cacheability-aware</strong> and stop exposing elements Webform would not render:</p> <ul> <li>Bubble the <code>#cache</code> metadata (tags, contexts, max-age) of every element render array into the GraphQL field context, so it is merged into the response's cache metadata &mdash; the same mechanism GraphQL already uses elsewhere. This includes honouring <strong>max-age</strong> (e.g. <code>0</code> for uncacheable elements) rather than only tags/contexts.</li> <li>Resolve <code>defaultValue</code> through a dedicated <code>webform_element_default_value</code> data producer that renders the default value in a render context and captures the resulting cacheability, instead of reading a bare value. This is what makes token-derived and entity-derived defaults safe to cache. A read-only producer keeps the logic testable and reusable by the per-element issues.</li> <li>Fix the <strong>cacheability leak from token resolution</strong>: tokens replaced while building element data must contribute their cache metadata (e.g. <code>user</code> context) to the response.</li> <li>Exclude elements that are not meant to render on the form from the exposed element list, and make an unavailable form return no stray elements.</li> </ul> <p>The kernel test base (<code>GraphQLWebformKernelTestBase</code>) gains assertion helpers for asserting the response's cache tags / contexts / max-age, so every per-element issue that follows can assert cacheability honestly.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Bubble element render-array cacheability (tags, contexts, max-age) in <code>src/Plugin/GraphQL/DataProducer/WebformElements.php</code>.</li> <li>Add <code>src/Plugin/GraphQL/DataProducer/WebformElementDefaultValue.php</code> and route <code>defaultValue</code> through it.</li> <li>Fix the token-resolution cacheability leak.</li> <li>Exclude non-renderable elements in <code>WebformElements.php</code> / <code>WebformElementMetadata.php</code>; return no elements for an unavailable form.</li> <li>Add cacheability assertion helpers to <code>tests/src/Kernel/GraphQLWebformKernelTestBase.php</code>.</li> <li>Tests: <code>DefaultValueTest</code>, <code>DefaultValueTokenCacheabilityTest</code>, <code>TokenPrefillCacheabilityTest</code>, plus updated expectations for existing element/markup/title tests now that cache metadata is reported.</li> </ul> <h3 id="summary-api-changes">API changes</h3> <p>No schema shape changes. The <strong>cache metadata of responses changes</strong>: responses that were previously (incorrectly) cacheable now carry the correct cache contexts/tags/max-age &mdash; e.g. token-derived default values gain a <code>user</code> cache context. This is a correctness fix, not a field addition.</p> <h3 id="summary-release-notes">Release notes snippet</h3> <p>Element data (default values, options) now correctly propagates Drupal cache metadata into the GraphQL response, so per-user and entity-derived values are no longer over-cached, and elements that Webform does not render are no longer exposed as placeholder entries.</p>