## Summary `AiContextItemListBuilder::render()` uses `CacheableMetadata::applyTo()`, which replaces `#cache` instead of merging it: - Lines 1029-1031 replace the table cache metadata that core `EntityListBuilder::render()` sets. The `ai_context_item_list` tag is lost. - Lines 1043-1044 apply the view-access metadata, then replace it with the scope-label metadata. The view-access contexts are lost, including `user` for Drafts that other users own. The tags of hidden items are lost too. - Line 589 replaces the cache metadata of the child label cell with the settings-access metadata, and line 777 then replaces that with the tooltip metadata. Nothing is lost there today, because `renderInIsolation()` adds the required cache contexts, and `user.permissions` is one of them. **Impact today: none on a site with default caching.** The listing is an admin route, and Dynamic Page Cache never stores admin routes (`DenyAdminRoutes`). Each request builds the list again with the access checks of the user who views it. This was checked on core 10.5.8, 11.2.10, 11.3.3 and 11.4.4. If a site or a later change caches this page (for example, a route subscriber that removes `_admin_route`): - Core 10.5 and 11.2: a user with the same roles can get the owner's page, with the owner's Draft rows (label, purpose and scopes). - Core 11.3 and later: row operations still carry the `user` context. The owner can get another user's page with their own Draft missing. Nothing is disclosed. - All versions: a new item does not show until caches are cleared, because the list tag is lost. The existing tests `testListCacheIncludesSettingsConfig` and `testListCacheIncludesDynamicScopeLabelMetadata` check only the metadata that survives, so they pass. !346 (#3586567+s, 1.0.1) keeps this problem. It merges its own query-argument contexts after line 1044, but it does not change lines 1029-1031 or 1043-1044. This issue merges first, and !346 then rebases on it. Part of #3586615+s. ## Proposed resolution - Lines 1029-1031: start from `CacheableMetadata::createFromRenderArray($build['table'])`, add the `ai_context.settings` config as a dependency, then apply it. - Lines 1043-1044: start from `CacheableMetadata::createFromRenderArray($build)`, add `listAccessCacheability` and `scopeLabelCacheability`, then apply it once. - Lines 589 and 777: merge the settings-access metadata and the tooltip metadata into the existing `#cache` in the same way. - Optional: in `AiContextItemAccessControlHandler`, add `cachePerUser()` for update and delete when the account has an "own" permission but is not the owner (lines 179-182 and 192-195). - Not in this issue: line 1032 sets `$build['#empty']`, which nothing renders, because core reads `$build['table']['#empty']`. So the "Add one" link never shows on an empty listing. This is a separate bug, to be filed as its own issue. ## Testing instructions Setup: 1. Use a site with the Standard profile, Drupal 11.3 or later, and the build under test. Write down the Drupal version and the CCC commit. 2. As an administrator, confirm that **Internal Dynamic Page Cache** is enabled (`/admin/modules`), and that **Do not cache markup** is not checked (`/admin/config/development/settings`). 3. Open the front page and reload it two times. In the browser developer tools (Network tab, first request), the `x-drupal-dynamic-cache` response header must show `HIT`. If it never shows `HIT`, caching is off on this site. Ask a developer to turn it on before you continue. 4. Create the role "CCC QA viewer" with only **View AI Context Items in CCC**. Confirm that neither this role nor Authenticated user has **Administer AI Context**, **View any unpublished AI Context Item** or **View any unpublished content**. 5. Create the users qa_a and qa_b, each with only the "CCC QA viewer" role. 6. As the administrator, create "QA published" with only the Global scope, and save it as Published. 7. Use three browser sessions: qa_a (normal window), qa_b (private window), and the administrator (a different browser). Test: 8. As qa_b, open `/admin/config/ai/context/items` and reload it two times. Expected: "QA published" is listed, and the header is `UNCACHEABLE (response policy)`. Write the header down. - If it is `HIT` or `MISS`, stop and report a blocker. - If it is `UNCACHEABLE (poor cacheability)`, step 13 cannot be used on this site. Continue with the other steps. 9. As the administrator, create "QA draft A" with only the Global scope. Set **Authored by** to qa_a, and save it as Draft. 10. As qa_a, reload the listing three times. Expected: "QA draft A" and "QA published" are listed each time. 11. As qa_b, reload the listing three times. Expected: "QA draft A" is not listed. Then reload as qa_a. Expected: "QA draft A" is still listed. 12. As the administrator, clear all caches. Open the listing as qa_b first, then as qa_a. Expected: qa_b does not see "QA draft A", and qa_a does. 13. Cache-data check: as qa_b, reload the listing and compare the header with step 8. - Bug present (expected on rc2): `UNCACHEABLE (response policy)`. - Fixed: `UNCACHEABLE (poor cacheability)`. 14. Old-list check: as the administrator, make each change below. Reload the qa_b listing after each one, and do not clear caches. - Add "QA new" as Published: it appears. - Rename "QA published": the new label shows. - Publish "QA draft A": it appears for qa_b. - Delete "QA new": it is no longer listed. 15. Report the Drupal version, the CCC commit, every header value, and the result of each step. Then delete the QA items, the two users and the role. Result: - **1.0.0 blocker** if any of these happens: a listing request shows `HIT` or `MISS`; qa_b sees "QA draft A" while it is a Draft; qa_a's own Draft is missing; a change does not show after one reload. - **Expected on rc2 without the fix:** all checks pass, and step 13 shows `UNCACHEABLE (response policy)`. This confirms the cache-data bug, which has no effect today. - **Expected on rc2 with the fix:** all checks pass, and step 13 shows `UNCACHEABLE (poor cacheability)`. ## Remaining tasks - [x] QA: run the QA check and report the results. Done on `1.0.x` (`f7c59f4`) and on the fix (`4c3af7e`) by @dcgoodwin (note 4680926), and on the fix by @jucs7 (2026-10-29). - [ ] Optional for 1.0.0: if the fix is RTBC before the code freeze (2026-11-09), merge it for rc2. Otherwise it stays in 1.0.1. - [x] If the QA check finds a 1.0.0 blocker, move this issue to 1.0.0 as a must-have. No blocker was found. - [x] Merge the cache metadata in `render()` and at lines 589 and 777. - [x] Kernel test that fails on 1.0.x: as qa_b, the table cache has `ai_context_item_list` and `config:ai_context.settings`, the build cache has the `user` context and the tag of the hidden Draft, and the Draft is not in the rows. - [x] ~~Functional test: a test module removes `_admin_route` from the listing route, with Dynamic Page Cache on.~~ Not required for this issue (maintainer decision, note 4679868). - [x] Decide the optional access handler item. Decided: not in this issue. - [x] File the `$build['#empty']` bug as its own issue (1.0.1), and link it here. Filed as #3586692+s. - [ ] Merge after !352 (#3586586+s) and before !346 (#3586567+s). This MR rebases cleanly after !352. !346 then rebases on this fix (2 hunks in `render()`). - [x] QA: run step 13 again on the fixed build. Result at `4c3af7e`: `UNCACHEABLE (poor cacheability)` (note 4680926). ## Release note The context items listing now keeps its list cache tag and the per-user access cache data. Sites with default caching see no change. ## Environment - Module version: 1.0.0-rc1 (8a57807); 1.0.x has no later commits. - Core: checked on 10.5.8, 11.2.10, 11.3.3 and 11.4.4. > [!note] > Check the one that best describes your usage, or leave all unchecked if AI was not significantly used. > > * [ ] AI **Assisted Issue** \ > _Mainly written by a human; AI used for partial generation under full human supervision._ > > * [x] AI **Generated Issue** \ > _Mainly generated by AI, reviewed and approved by a human before this issue was created._