## Summary When an issue's work item **status** auto-transitions as a side effect of a state change (close -> a `done`-category status like "Complete", reopen -> an open-category status), that status change is **not reflected in the issue webhook `changes` payload**. Consumers that watch `changes.status` never see the transition, so downstream automation that reacts to status changes is silently skipped. Found while dogfooding work item status internally (triage-ops status/label sync). Filing from the internal-adoption angle, but it also fits the broader status technical follow-ups. ## Impact Our triage-ops status <-> `workflow::` label sync reads `changes.status` to mirror a status change onto the workflow label. Because the close-derived status change is absent from the webhook, the sync does not fire on that path, leaving the item with a **status that disagrees with its workflow label** (e.g. status "Complete" while the label still says `workflow::refinement`). Low blast radius for us specifically (we no longer care about workflow labels on closed items, and they are being retired), but the underlying behavior is incorrect and affects any consumer relying on `changes.status`. ## How `changes.status` is meant to work `status` is not a column on `issues`; it lives in `work_item_current_statuses`. It is injected into the webhook `changes` hash explicitly in `ee/app/models/concerns/ee/issuable.rb`: ```ruby if supports_status? && (old_current_status(old_associations) != status_with_fallback) changes[:status] = [old_current_status(old_associations)&.hook_attrs, status_with_fallback&.hook_attrs] end ``` with ```ruby def old_current_status(assoc) @_old_current_status ||= assoc.fetch(:status, status_with_fallback) end ``` For `changes.status` to appear, three things must all hold: 1. `old_associations[:status]` is captured **before** the update, in `ee/app/services/ee/issuable_base_service.rb#associations_before_update`: `associations[:status] = issuable.status_with_fallback`. This call **loads and caches** the object's `current_status` has_one association (old value). 2. The update hook (`IssuableBaseService#update`) fires with `old_associations`. 3. At hook-build time, `issuable.status_with_fallback` reflects the **new** status **on the same object instance** whose old value was captured in (1). Condition (3) is what breaks. ## Root cause `WorkItems::Widgets::Statuses::UpdateService#ensure_work_item` reloads a **fresh `WorkItem` instance** when it is handed an `Issue` (`ee/app/services/work_items/widgets/statuses/update_service.rb`): ```ruby def ensure_work_item(work_item) return work_item if work_item.is_a?(WorkItem) WorkItem.find_by_id(work_item) if work_item.is_a?(Issue) end ``` The close/reopen status transition is applied through this service via `ee/app/services/ee/issues/base_service.rb#update_status_after_state_change`: ```ruby def update_status_after_state_change(issue, status) status = :default if status.nil? && (issue.current_status || lifecycle_for(issue)&.custom?) ::WorkItems::Widgets::Statuses::UpdateService.new(issue, current_user, status).execute if status end ``` So the sequence for a state change is: 1. `associations_before_update` reads `issue.status_with_fallback`, **caching** the `issue`'s `current_status` at the old value. 2. On close/reopen, the status transition runs against a **separately reloaded** `WorkItem` (from `ensure_work_item`), and saves the new `current_status` on **that** object. 3. The original `issue.current_status` association is **never reset**. 4. The update hook reads `issue.status_with_fallback` -> returns the **stale cached old status** -> `old_current_status == status_with_fallback` -> the `changes[:status]` branch is skipped. The result: the DB has the new status, but the webhook says nothing changed. ## Reproduction (verified in Rails console, GDK 19.2.0-pre) Setup: a group with a custom lifecycle (statuses incl. "In dev" and "Complete"), a project, and an issue set to status "In dev". **1. The stale association is directly observable.** After closing the `Issue` object, `status_with_fallback` on the same instance still returns the old status; resetting the association returns the new one: ``` issue.status_with_fallback&.name # => "In dev" (stale, DB has Complete) issue.association(:current_status).reset issue.status_with_fallback&.name # => "Complete" (correct) ``` **2. The webhook omits `changes.status`.** Closing bundled with another attribute change (so the `update` hook fires with `old_associations`) still does not include the status: ``` # before fix action=close changes=[closed_at, state_id, updated_at] status_present=false action=update changes=[closed_at, state_id, title, updated_at, ...] status_present=false ``` ## Fix Reset the caller's `current_status` association after the state-change status update, so the object the webhook reads reflects the new status. This is the smallest correct fix and covers **both** close and reopen, since both route through `update_status_after_state_change` (`ee/app/services/ee/issues/close_service.rb` and `.../reopen_service.rb`). `ee/app/services/ee/issues/base_service.rb`: ```ruby def update_status_after_state_change(issue, status) status = :default if status.nil? && (issue.current_status || lifecycle_for(issue)&.custom?) return unless status ::WorkItems::Widgets::Statuses::UpdateService.new(issue, current_user, status).execute # The status service may operate on a separately-loaded WorkItem instance. # Reset the association so the webhook `changes` builder sees the new status. issue.association(:current_status).reset end ``` **Verified:** with this patch applied at runtime, the `update` hook now emits the transition: ``` # after fix action=update status_present=true changes.status = [{name: "In dev", category: "in_progress"}, {name: "Complete", category: "done"}] ``` The status write is a synchronous `save!` committed before the outer update hook fires, so the reset re-reads the committed new value within the same request. ### Alternatives considered - **Make `ensure_work_item` not swap instances / write through to the passed-in `Issue`.** Rejected: the status UpdateService is called from many places (callbacks, bulk updaters) that legitimately pass a `WorkItem`; too much blast radius. - **Add status to the `close` hook's `old_associations`.** Wrong locus: the `close` hook carries no association diff and would risk double-emitting. The correct place is the existing `update` hook, which already carries `old_associations[:status]` and just needs the instance to reflect the new value. ## Tests to add - `ee/spec/services/ee/issues/close_service_spec.rb` - close an issue that has a status and assert the emitted issue webhook `changes.status` = `[old, new]`. - `ee/spec/services/ee/issues/reopen_service_spec.rb` - symmetric coverage for reopen. - Optionally an integration spec closing via the `/close` quick action and asserting `changes.status` in the webhook, to lock the originally reported scenario. ## Open question On GDK, all service-level close paths (`Issues::UpdateService`, `WorkItems::UpdateService`, and the `/close` quick action via `Notes::CreateService`) behaved identically - none emitted `changes.status` before the fix. In production we observed the **web UI** close sync correctly while the **`/close` quick action** did not, which suggests the UI status change may travel via a separate GraphQL status-widget mutation (which does carry `changes.status`) rather than the close cascade. That specific UI-vs-quick-action divergence was not reproducible on GDK, but it does not change the fix: the fix makes any state-change-derived status transition appear in the webhook regardless of the entry point. ## References - Internal adoption epic: gitlab-org&19642 - Example issue where the mismatch was observed: gitlab-org/gitlab#604633 (status "Complete", label `workflow::refinement`) - Consumer affected: triage-ops status/label sync (`triage/processor/workflow/status_label_sync_processor.rb`)