## TL;DR The work item detail page reads the full workplan from object storage on every load, even though most of the time it only needs to know **whether a plan exists**. Once https://gitlab.com/gitlab-org/gitlab/-/merge_requests/251354 lands, `hasContent` on `WorkItemWidgetAgentPlan` answers that from a database column. This issue moves the frontend onto `hasContent` and **fetches `content` / `contentHtml` only when the workplan panel is opened**. Backend counterpart: https://gitlab.com/gitlab-org/gitlab/-/work_items/616229 ## Problem `implementation_widget.vue` runs `workItemAgentPlan` (`ee/app/assets/javascripts/work_items/graphql/work_item_agent_plan.query.graphql`) as soon as the work item detail view renders. The query includes `WorkItemAgentPlanFragment`, which selects `content` and `contentHtml`. Resolving either one costs an object storage round trip on the backend, so we pay a GET plus latency on every detail page load, for every work item with AI planning enabled. Most of those reads are thrown away. Outside the panel, the frontend uses `content` for state only: - `work_item_workplan.vue` derives `hasSavedContent` from `content` and passes it to `workplan-inline-row` as `has-content`, which decides between the "Plan" / "Generating" / "View" states. - The `workplan` watcher in `work_item_workplan.vue` compares old and new `content` to detect that a run wrote its plan (`planLanded`). - `workplanViewState` checks `content` and `contentHtml` to decide whether to fire the view tracking event. On top of that, the same fragment is used by: - **Polling** while a run is active (`ACTIVE_RUN_POLL_INTERVAL_MS`, every 10 seconds), so each poll reads object storage again. - **The `workItemAgentPlanUpdated` subscription**, so every `workItemUpdated` event re-resolves `content` for every open tab subscribed to that work item, including updates that have nothing to do with the plan. The panel itself (`workplan_panel.vue`, `workplan_view.vue`) is the only place that actually needs the markdown. ## Proposal 1. **Add `hasContent` to the fragments the widget always loads** and drive `workplan-inline-row`'s `has-content` from it instead of from `content`. 2. **Split `content` and `contentHtml` into their own query** (or a separate fragment on a query) that runs only when the panel is open. Skip it while `isPanelOpen` is false. Keep it out of the polling query and the subscription. 3. **Replace the content comparison in the `workplan` watcher.** A first plan shows up as `hasContent` going from false to true. A regenerate keeps `hasContent` true, so that case needs a different signal. Options: refetch the content query when `generationStatus` leaves an active state while the panel is open, or rely on `generationStatus` alone and drop the early "plan landed" shortcut. To decide during refinement. 4. **Update `cache_utils.js`** so writes after save/delete keep both queries consistent: `hasContent` in the widget query, `content` / `contentHtml` in the panel query. 5. **Mutations** that share `WorkItemAgentPlanFragment` can keep returning `content` where the response is already used to update the open panel. They are writes, so the cost there is expected. `hasContent` is an experiment field introduced in 19.6, so selections need `@gl_introduced(version: "19.6.0")`. ### Known caveat Rows that existed before https://gitlab.com/gitlab-org/gitlab/-/merge_requests/251354 report `hasContent: true` even when they only ever held an empty document (accepted on the MR, see https://gitlab.com/gitlab-org/gitlab/-/merge_requests/251354#note_3978526316). For those, the inline row shows "View" and the panel opens on an empty plan. The panel should handle empty `content` gracefully (it already renders an empty state in `workplan_view.vue`), and the inline row can fall back to the "Plan" state once the panel query returns no content. ## Acceptance criteria - [ ] Loading the work item detail view does not request `content` or `contentHtml` while the workplan panel is closed. - [ ] The inline row shows the correct state (no plan, generating, plan available) based on `hasContent` and `generationStatus`. - [ ] Opening the panel fetches `content` / `contentHtml` and renders the plan. Closing and reopening uses the Apollo cache. - [ ] Polling during an active run and the `workItemAgentPlanUpdated` subscription do not select `content` or `contentHtml`. - [ ] A finished run (first plan and regenerate) still shows the new plan without a page reload when the panel is open. - [ ] Saving, editing and deleting a plan keep the inline row and the panel in sync. - [ ] The workplan view tracking event (https://gitlab.com/gitlab-org/gitlab/-/work_items/630735) still fires only when a plan is actually shown. - [ ] Jest specs cover the new loading behaviour. ## Blocked by - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/251354 (adds `hasContent`) ## Related - Backend issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/616229 - Database review discussion on why this matters: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/251354#note_3973043479 --- :robot: _Crafted with the help of AI_